I really like your approach. My idea in the other FR was way to big and I thought my use case is so particular that it makes not sense to implement such a thing.
However starting with simply allowing whiteboards to be parts of pages would already unlock so many features. Implementation wise, I think most of the tooling would already support it, as whiteboards are in fact blocks in the database. The UI simply does not allow you to create them as a block on a page.
One problem however is storage! The page it self is a markdown file (this will change with the db-version). If you want to store the whiteboard in the file, the markdown file becomes unreadable as any element on a whiteboard has a corresponding block with lots of properties. The underlying markdown file thus becomes pretty much unusable for external tools.
I think it would be a lot of work to adapt the file parser to parse subsections of the markdown file as a whiteboard and if you make changes externally your whiteboard would break most certainly as logseq could not load it any more.
Maybe a solution would be to allow whiteboards as page blocks for the db-version only?