It’s great to see this article and get an increasingly clearer idea of where you are trying to go with Fibery. The goals make a lot of sense, to be sure.
I think one of the key insights and realizations for me is that implementing chat in Fibery actually does totally make sense (whereas until recently I felt it would be a big distraction and waste of dev resources). I suppose I’d have to say I am probably better able to appreciate this now after having spent a year or so using Slack in a business context, as well as participating in a variety of Discord servers. Prior to that my real time discussion (i.e. chat) use was quite limited, for the most part just to people I knew (WhatsApp/Messenger/SMS/etc). And I now see that indeed people do use chat a lot to (try to) get work done. From my perspective it is often tremendously inefficient, and prioritizes immediacy and low friction over all else, to the detriment of many other factors. But… there is no denying that people work this way, and that to some degree they want to.
And yet Slack (and all other current chat systems as well) is a horrible tool for collective sense making, and an even worse one for long-term knowledge organization and maintenance. Zulip does a bit better job, at least with its particular take on “threading”, etc. But again they are both inferior to collaborative documents (e.g. GDocs, Fibery), entity-based comment threads, etc. in many respects, to say nothing of the value of structured data that is also attached to those Entities. It’s just that they (Slack and the like) take far less discipline to use them well, so even though the results are not as good, not as structured, it is “easy” and “quick” and the clarity of the downsides only comes in hindsight, for the most part. And so likely we cannot fight this tendency directly.
So what is needed is a way to connect “chat” to “real work” in far more direct ways. Not just “Create task from this Slack message” (as we already have now), but e.g. “transclude these 3 chat messages into this Entity” or “instantiate chat on this entity” or “count the votes on this chat message in a formula on this entity to derive a score”, etc, etc.
Interestingly there are other companies who are further along on this path in at least having integrated chat, but so far no one appears to be doing well at figuring out how to do deeper integration like this. ClickUp has surprisingly rich chat built-into it already for instance (and I hope you can follow their example and make Fibery chat messages very “rich” and capable!), in fact I think they have had it for some 2 years now! But when I have used ClickUp in teams, they never used the chat. Why is this? It seems to me the first step along the road of the needed unification is just to get the feature adopted. I think you know that moving people off of Slack is going to be a tough sell, so hopefully you have now (or will eventually have) some good ideas for making that happen. 
It is probably the toughest nut to crack, but getting people to use an in-app chat is likely the one integration of functionality that would have the biggest impact on adoption of any centralized work management tool. So I’m glad you also see that, and now wonder about its priority, etc… (while also acknowledging the difficulty of prioritizing the nearly unlimited backlog, and that I also just posted my own lengthy argument for prioritizing Whiteboards instead of other things 
)
I also want to point out what I think is an important nearer-term capability that will arguably be vital to achieving this long-term vision:
Assuming these “properties” could include “type”, this is critical to “sense-making” in my view. Here’s a key example within the “Product Companies” niche that is often referenced in Fibery context.
Take the now-familiar Fibery superpower of linking some random text to some entity and thus creating a “reference”. Hooray, we know this text is related to this entity. Now in your recent “How Fibery uses Fibery” video, you talk about how this process can let you quickly create an understanding of the less immediately quantitative information about product needs, etc. Very important! The problem is not all information is expressing the same “sentiment”, e.g. some may be in support of something, while other information may be opposed to it. How do we deal with this? Well, in current Fibery model I guess we’d have to an entirely new “Insight” Type with a Field you mark “support” vs. “oppose” and only link to one or the other, depending on need, etc. Then link those to your “Feature” or whatever, and calculate support vs. oppose via formula. It probably works but it’s a bit hacky.
What if instead you just had a “type” for the relationship? When you create the reference, you indicate whether it supports or opposes the entity being referenced. Better still, while in the current model you can only really either loosely evaluate the references by reading them all, or inaccurately evaluate them quantitatively by simply counting them, with relationship properties (assuming you can have multiple), you could also have a “strength” or “importance” value along with support/oppose value. Now we can evaluate the strength or importance of each reference as we go, and then on the other end - the referenced entity - it is trivial (and also far more accurate) to then quantify the data and get a numeric “correctness” or “level of support” value for that entity.
Now we bridge a huge (IMO) gap in the whole concept of insight generation, etc. because we can actually codify and act on more of the understanding and information we actually do already have in our heads while we work across broad swaths of source data. Yes, it will still not be perfect. One evaluator of claims may have a different judgement of “strength/importance” than another (hey, you can formally express that in relationships too, if you need to!), etc. But it’s a big improvement over what we have.
This is really just my take on something I read today, which I immediately connected back to Fibery and this recent article (after having some similar thoughts while originally reading Michael’s view):
Of course it gets quite complex, and it’s a question of UI/UX as well as back-end, performance, etc. Do we want to have a Relationship with a Type and Strength as well as Author? Yes, OK, and maybe we assign different “authority” to different authors, such that we can calculate the value of their data (e.g. their weighting of importance). We can filter by who created what relations, allow relations from multiple people between the same objects with different Property values, etc. Do we even want to have Properties on Properties? (probably not for a while, if at all?)
Rob Haisfield (author of the above article on data structures to facilitate decentralized knowledge synthesis) goes further, incorporating block relationships, and more:
My current thinking is that the most valuable set of primitives are basically: typed concepts, typed relationships, expressive user-generated data structures, and rules. I want to be able to write in blocks with inline data structures, arbitrary relationships between blocks, block referencing, inline querying, and inline coding.
Q- What are powerful primitives for a user of a decentralized knowledge graph
And some further depth on related topics, though more disconnected from Fibery’s central (current) use cases. The whole ScalingSynthesis.com site is quite interesting for this “second brain for teams” concept area: