Please consider prioritizing this higher. It’s actually really helpful for research and handling product feedback, etc. from sources Fibery doesn’t support natively. For example rather than using a generic Web Clipper (or having to develop specific e.g. Twitter connection for Fibery), instead just leverage the many input sources that Readwise already handles, and then connect that to Fibery and you suddenly have a very powerful “ingestion engine”. Takes the pressure off e.g. your own web clipper, perhaps. And also I hear Readwise is very easy to work with for devs, has a good API, etc. Would probably also make Fibery more visible in the general PKM community as lots of people are hyped about Readwise. If you are not already thinking about integrations as a marketing channel, you should be. 
This is a common workaround for many Fibery limitations, but it only works for certain things. In this situation I’m fairly sure it doesn’t go very far to address the underlying need. If I’m not mistaken, she wants something similar to the “Strange New Worlds” plugin for Obsidian:
(correct me if I’ve misunderstood @Sarah_Arminta )
I think you give some fairly good example use cases here. But I must agree with Michael, despite watching closely across the PKM/TfT community for years now, I have seen very, very few actual use cases for automatic graph views in personal knowledgebases (mindmaps and e.g. “tree maps” are a different story). Not to say that they do not or cannot have utility, but it’s quite uncommon for people to be able to actually describe tangible and specific value from those kinds of features. I personally suspect that an “actionable” and “insightful” graph view has simply yet to be designed or implemented, but I think there is a lot of potential value there, with the right design and affordances. I also think graph views can have perhaps more obvious value in other contexts besides PKM (think for example of word relation models as a way to explore synonyms or the etymology of a word).
A Daily Notes Page is just another kind of Database, with a Date field(s), etc. I record everything in bullets in Rich Text. I frequently #reference other Databases/Entities, etc. to establish ad-hoc links. The two missing features to fully enable this kind of workflow are Transclusion and Blocks). Both are coming. Once we have Transclusion, we can write something in a Daily Note Entity, then Transclude it anywhere else we want, thus being able to organize our unstructured Daily Notes into multiple more structured places. In the meantime we can highlight-link in Fibery and it will show up in the References of the linked-to Entity, which is not as good, but not bad either. References can also be operated on with formulae to e.g. generate a field showing references within the last X days, etc. (I haven’t done this, but fairly sure it’s possible).
I have a couple of Projects/Tasks setup specifically for this. 
Basically “come back and do something with this later”, and it reminds me on a schedule relevant to that kind of thing, daily, weekly, etc. When the reminder comes up, I go look at the References for that Entity and see if there are any I haven’t processed yet. I may or may not Unlink the ones I’ve processed at that time, to make it easier to see the new ones next time the task comes up.
Aren’t “dashboards”, as defined by e.g. Notion, basically going to be enabled by the coming Blocks efforts? Being able to embed View blocks, etc. will make Fibery at least as capable as Notion in this respect, and more so given the powerful Charts for example. Only real limitation will be lack of “columns”, I think (though maybe/hopefully you have a column block type planned ).
I am similar, though not quite as in-depth as you, it seems. But I would also suggest you consider how many things actually need to be their own Database. You basically have two major tools for differentiating a “type” of thing. You have the Database itself, which is a “heavy” solution, creating major distinction between things, and databases are particularly distinguished by their set of fields. And then you have Fields and their Values, so e.g. you can have a single “Documents” database, but have a single or multi-select Field that is a “Type”. This is a “fiction” document, that is a “poem”, etc., and they can be distinguished by a single Field denoting a “Type” (single or multi-select). Then you can e.g. create a View (Table, List, etc.) that only shows Poems vs. Fiction (or colors each differently).
The main limitation on using a regular Field for e.g. “type” distinction is field values cannot be shared between databases, so if you want to define common “types” between databases, that’s when you’d use a separate Database for those “type definitions” themselves (i.e. “tags”), and then use a Relation to multiple other Databases to define that commonality (essentially allowing shared values between multiple databases for a common field).
So do you have Fields that are specific to “fiction” that would not be shared by “poem”? Or between different kinds of “products”, e.g. a candy bar vs. a can of soup? Maybe, maybe not. I only create a new Database if the content I’m wanting to contain in it has a sufficient amount of unique field-type (i.e. structured) data. If there are just 1 or two but several other Fields are shared by another, similar “type”, then I’ll often just add those extra fields, knowing they’re only used by some of the Entities in that Database, but it’s acceptable (especially now that we can Hide fields, Collapse fields, etc.). Also this would be further helped by Individual Layouts for a node, hide fields etc.
Now all of your examples above may in fact have enough different structured data elements to justify being their own DBs, but they (or others you haven’t mentioned) may not, and could perhaps just be distinguished by one or more field values on a more generalized Database “type” (e.g. “documents”, “notes”, etc).
I would say the Color options are quite basic and inconsequential through the Fibery system right now, which is to say that they are confined to the View they are defined and shown in. I think there are one or two prior requests about more system-wide, “intrinsic” color properties of entities/databases/fields, which I think would be nice to have.
So, having read through this thread thus far, and seeing that you and I have similar, broad personal data management needs, and also being a fairly long-time Fibery user, I can speak to the choices I’ve made and the principle challenges I see in implementing my own workflow and hopefully that will be helpful. Currently I am all-in on Fibery, for reasons I outlined in the other topic. In large part my own limitations of time and brain power are the main impediments to a complete setup as I envision it. Which is why I hope to share my template(s) when I’m finally done. Other than that, I continue to make feature requests, bug reports, and advocate here in the forum for the many things I think are needed, both for my personal use case and, as much as possible, for broader business use cases.
There are relatively few thing truly “missing” for me to get most of what I want done, er, done. In some cases there may be a bit more rigidity than I’d like, I may have to do some workarounds where another app might have native functionality. But at the moment Fibery still feels like the best option for building this kind of all-in-one integrated system, whether for personal or business use, especially if you take data portability into consideration (last I heard Tana only bulk exports JSON?). But there are a lot of apps trying to tackle this general problem space, and a surprising number particularly aimed at the personal, or at least personal-first use cases (as opposed to business-oriented tools like Fibery). Tana, Capacities, Mem.ai, Anytype, and of course Obsidian, Logseq, etc.
As I also mentioned in the other topic, Tana is really the main app that is potentially diverting my investment in Fibery at all right now. No other team seems to have thought through how to handle the transition between unstructured and structured data as well as the Tana folks (I mentioned several other cool apps here, but only Tana seems to be well-architected and rapidly evolving enough to currently be a real contender as an in-depth PKM like we’re discussing here). So I think what you’ll have to do is just decide how important ad-hoc data organization is to you. For me one of the biggest pain points with Fibery is lack of combinatorial “types”, property inheritance/combination, etc., and “Polymorphic relations”.
One of Tana’s great powers is the ability not just to progressively structure content into “data”, ad-hoc and in-line, but to then combine those structures on-demand, as-needed, and in non-rigid ways. The ability to use multiple supertags and get the fields of both applying to the current block(s) is incredible, IMO. Fibery cannot do that as far as I understand, and probably never will. At the same time for me Tana isn’t quite structured and “bespoke” enough, in design, in page structure (outliner), etc. But that stuff ought to be easy enough to add, if they decide to (that’s the big unknown to me: what is their future plan, where are they heading with Tana, will it always be a strict outliner? etc.). To be clear, I do not yet have access to Tana, but I’ve watched a ton of videos of how people use it.
But basically that’s the tension I see: very strong structured data functions and bespoke design oriented toward that model, e.g. Views, Charts, etc. (Fibery), vs. ad-hoc, flexible, page-level data, i.e. blocks + in-line Views, etc. (Tana). The two are not entirely incompatible, but they are based on fundamentally different data models AFAIK (graph vs. more traditional DB, I believe). Fibery is further along than Tana in many respects, but Tana does things Fibery doesn’t yet do and perhaps never will. Tough choices. For now I continue to invest in Fibery. Maybe if I got access to Tana it might change my mind For personal use, mind you, not for business use. Fibery is still king there for me.