There are quite a few developments there: conditional view templates that apply when a fieldname node is in the story river (whether or not it’s a tiddler), and modifications to the edit-fields interface so that fieldnames can be links.
It strikes me that both of these developments could and should be extended to work with a cascade — perhas there’s even a preference setting for whether to prefer the $:/fieldname/-prefixed naming convention (or some variant), and clicking on a field name in edit mode opens the node accordingly (with or without the prefix). And it’s fairly easy to make virtual nodes helpfully redundant (so that if there isn’t a tiddler, the node “looks” to see whether it’s a fieldname, or whether it’s a fieldname-after-system-prefix (etc.), and gets templates accordingly. Perhaps there’s an easy way to ensure that if a system-namespace convention is chosen, simple fieldname tiddlers will ignore any connection to the fieldname, if that is preferred (so that a tiddler called “library” can be used without the distraction of seeing field-definition and details for the more technical use of that fieldname).
I’m scrambling with work tasks these days, so I’m not able to implement the cascade mechanism very soon.
I would simply nudge you — as you’re developing your variations — not to condense too many things into a single “field-type” concept, because there may be overlapping things that are true of fields that might all be understood as “kinds” or “types” of field: One and the same field might contain date value(s) (for example), and be a list field where values should be readily linked; A field may hold person-names, and again this fact is compatible with its being or not being a list field; a field may be a filter field AND need a generous textarea input interface. In other words, there are at least three or four dimensions that might play a role connected to something like “field-type”: INPUT-interface, FORMAT (as in date formats), QUANTITY (do the contents get parsed as multiple identifiable values), and/or FUNCTION(S) (as in: persed as filter, parsed as [raw] value-list, or … [eventually] validated for uniqueness/valid-color-value/valid-date-plus-time value, etc.).
I look forward to rejoining the fray with more attention, probably in another 10–12 days.