Following up on @Oshyan 's comment, I am struggling to understand the benefits of having view blocks appearing as distinct child views of a page (or every entity). I can see that there is value in embedding existing views (and having the ability to jump to the original/expanded view).
I understand that this approach will allows fibery to have a single way of addressing data views, but I think it might be better to have an embed block for actual existing views and separate table/board/calendar/… block views that render on the page load.
I also have concerns about scalability of this as users start to add multiple views in each document or entity view and if we are going to at some point allow for other types of blocks to be added (perhaps developed by external developers).
I was hoping that the view blocks would actually be very lightweight components that are populated/updated when rendered. One of the things I wanted to be able to do with the view blocks was to build daily notes pages that have combination of text notes and reflections as well as meeting calendar view, todo table/board views, etc. . Creating a new set of views every day seems like it is going to become unmanageable very quickly. Not to mention probably making search hard as well.
To allow the above to work, I also think that there needs to be a way of generating view blocks using markdown templates (with a way of representing what is shown textually). So when you autogenerate new Daily Notes (or any other recurring item), you will have the view blocks already added.
Finally, I think Formulas in filters would be an essential ingredient so that you are able to define one view and have it adjust/filter based on surrounding content/blocks (see this discussion).