A really interesting discussion started up in Telegram, and it felt far too in-depth and important to let it disappear over time there. So I’m continuing it here, and will be quoting and responding to the key messages of that discussion here. I hope everyone will continue discussing all of this here as I think it’s quite interesting and important.
This is an interesting perspective, but I don’t agree. I think simple tables are absolutely necessary/useful, at the very least for simple aesthetic formatting of non-structured content (non-structured in a “data” sense). Of course there is the column functionality of both Anytype and Notion to somewhat meet this need, and in fact I even raised the possibility of a new block formatting option for borders to help get a step closer to “tables made out of blocks”. However I still think a “simple table” block (or “markdown table”) makes sense.
Continuum or Spectrum of Functionality Concept
What I do agree with, that I think you are partly saying, is that contents needs to be able to be acted on in more structured ways at any time, as soon as it may become necessary. For that reason I think the more interesting thing to think about is a “continuum of functionality”, and an ability to in some way move in both directions along it. A capability, or a whole bunch of capabilities, to go from unstructured data, to increasing amounts of structure and functionality (this entire concept is an important meta consideration for the future of knowledge management and insight generation in general, IMO).
So for example, let’s say you start with a Simple Table. It has no functionality, no calculations, etc., it is purely aesthetic, and this is fine for a start. This is a useful thing to have. But then let’s say you realize you do want to perform some calculation or other data work on this information in this existing table. Ideally you could then very simple open the controls for the Simple Table Block that holds that data, and Convert it to a “Spreadsheet Block” or “Dynamic Table” or something. You could then do things like Sort, Calculate, and Filter. How this interacts with my request for in-line calculations I’m unsure, it could be a part of this “continuum of functionality”. Anyway, perhaps you eventually decide you now want to actually add lots of information and detail and formalized fields of data (relations) to the bits of info in your table, so again you use block options and convert it to “Table” (or “Set” perhaps) and it automatically creates Objects (pages) for every Row of that Table or Spreadsheet block, and replaces the prior block with an in-line Set view. Now all of your rows link to full pages, and each column becomes a Relation, etc.
Conversely, a non-destructive way to actually take a Table View of a Set (or a Spreadsheet block) and convert it to (ir at least view or instantiate it as) a Simple Table could be really interesting and cool too! I would imagine, due to the loss of significant functionality in the process, that you’d want it to output to a new block so as to be non-destructive. Perhaps it could even be a type of Block Reference for a Set: “Reference as Simple Table”. 
At a meta level this concept of being able to move along a “spectrum” or “continuum” of functionality while operating on the same/similar core data reminds me of some ideas and capabilities that the Fibery team is thinking about and working on. Initially those are outlined here:
And in ongoing discussion of their upcoming “blocks” functionality:
And while I think it is important to think of it in the context of “tables” as we do here, it is also important to extend this to thinking about how all content can be used and re-used in such ways (things like block references, transclusion, etc., at the least).
Yep, exactly. Although I think that A: naming these things with more familiar/intuitive concepts (as I hopefully did above under the “Continuum of functionality” heading/concept), and B: ranking them by level of functionality/sophistication, is helpful/important. So in my view that would change your #2 into a either 1 or 3 (depending on if you wanted greatest sophistication at the top or bottom), let’s say it’s #3 as it builds on simple tables. Simple tables, your #3, would be 1, and “active grid” (spreadsheet/dynamic table) would be #2. I think ordering it the way I’ve described maps more clearly to both the level of functionality available to the user, and the difficulty of implementation, both of which seem useful. Apologies if that seems pedantic, and I realize your own ordering may have some meaning to you that is lost in this reordering, so do explain if that was the case.
Well, parts of #2 already exist in the Table view of Sets. But yes, calculations don’t exist yet. That is definitely planned, however.
I don’t entirely agree, I think “simple tables” are very useful and necessary. I’d accept having to paste them from other sources (which is for example how Fibery currently works - you can paste in markdown tables, but not create or modify them within the Fibery editor), but I’d really rather be able to edit a table directly in the powerful and intuitive Anytype editor!
Not necessarily. Consider that the mere presence of additional functionality may be “cluttering”, distracting, and unwanted for people who just want “simple tables”. That said, if “Excel-like” (i.e. spreadsheet) Block in Anytype coudl be used as a Simple Table effectively, it might reduce the implementation scenarios from 3 to 2, so that is worth considering. You would still need to be able to paste in basic format-only tables, e.g. markdown tables. And it would need to be very simple to use so as not to distract or confuse anyone who just wants simple table design.
My understanding is everything is an “object”. “Document” has a particular implication that I’m not sure applies, but this may simply be a difference in terminology, our semantic intent/meaning may be the same.
Right, indeed!
Yes, I believe you are correct, generally speaking. However there is also the potentially unrelated or different concept of “blocks”, i.e. layout of objects within another object(s), on-page structural relationships (parent/child blocks), etc. And some aspects of blocks are purely aesthetic, rather than data-related, they do not hold any “value” (except if you look at the “value” for the setting of the block itself, e.g. underline text no/yes, or 0/1, color RGB value, etc.). Things like “simple tables” could be implemented in this way or could be a simple expression of a more sophisticated object-level functionality as I think you imply.
Good, let’s continue here then! 
I think I would just say that, while the way things work in the back end is cool and interesting to think about, without having access to the code (yet), it’s hard to be sure how it all works. Speculation may be fun but is not necessarily that useful ultimately (in my view). What matters now, IMHO, is what functionality people need, and how it works or should work, especially in terms of UI/UX, intuitiveness, ease of use, etc, etc.
This creates some notable limitations, to be sure, but they wouldn’t have provided the option if they didn’t see some utility for it, eh? I talked a bit about it and linked to some demo videos in an update in my digital garden: