I understand the problem and as a developer it’s okay for me to adapt to this for custom cases.
I also prefer to be able to use just text and create any nested structure like in JSON than not having the possibility.
As a fundamental entity (I’ll call this object as “entity” from now on), an interface or abstract class that defines an identifier and a dictionary/sortedlist of key-value pairs with the option of custom sorting. With standardized keys such as name, category/family, icon and some others that are commonly used, but always allowing custom pairs, like this same entity. Edit its content according to the key. With the option of being read only (that identifier cannot be overwritten or the developer of the type can only if he wants to). With methods to be convertible to text in various formats (abbreviated, complete or regular). Also that it can be exported to JSON and other formats.
I don’t think it takes much more, the idea is to share the same base type to store data between different applications (gh ↔ plugins). I see the arrays or lists as the last link or the leaf node, because they are not intended to be nested to form a tree structure, and for this it is highly necessary. This format allows to go towards abstraction, for example, I can make a collection of profile curves in a list, but if I need a collection of collections (because each type of profile belongs to a different field of use) I need another entity that group all collections. And if I also have other collections of other geometries, I need another more abstract entity to group them. Grouping, or rather, defining these more abstract concepts, we can build knowledge. We need the brick for this type of buildings.
I give you another example. This format also solves how to structure the metrics of the definitions. Each component has one of these associated entities, and its parameters as well, which are child entities, which contain a key with the list of source component/target component pairs and the number of times they have been connected. So, once you have this database of definitions, given a component, you can suggest a whole next process based on the user experience. If processes can be tagged (such as naming a group) and saved, then a sophisticated search engine could be made. For example, if you want to get the most commonly used processes related to the “curve” tag without using brute force, you need an entity called “curve” that contains those processes. More semantic modeling.
With respect to the above, there could be other types of objects responsible for launching events in certain circumstances of the software, where we can subscribe and generate new entities of these or update them in existing databases. I’m doing this for Peacock1, I call them statistic collectors, but I look limited in many cases and I think it’s a generalist feature that should have GH and not a jewelry plugin, but I want to make it as smart as possible and one of the ways is to measure.
Basically I want to control this type of data in GH as native type, with its corresponding parameter and exportable to/importable from a file. It is not very different from a JSON. And now that I think about it, this is not very different from your GH_IO, right? but the difference is to extend it to an individual entity that is able to generalize the use of the database.
A last example. Imagine that you create a façade generator, and suppose there is a controllable pattern of rows (entrance, floors, between floors, roof …) and each row is also divided into several spaces (balconies, between balconies, whatever, no I’m an architect). It should be a quasi-arbitrary mesh/graph and not rows and columns, but it’s just an example. Each of these spaces can contain a specific type of constructive element, that is, a label. With this generator, you can easily create a segmentation image that associates a color with a constructive element or label (instead of making a realistic render, it is colored by category), that is, the data necessary for one step of supervised learning of façade recognition (real image → segmentation → features). Regardless of technical difficulties, GH is perfect for generating databases for this purpose, or expert systems based on data that are a catalyst for learning from real data. Then, for each facade generated, there is an entity that keeps its characteristics of rows, columns, elements, whatever it is, no matter its structure, it is a tree.
I’m not sure I answered your question, but I think I have shown the need for this.