Edit: Watch twMat make a fool of himself. Well, it was a fun thought experiment regardless.
IMO fields should simply be tiddlers!
This would bring further conceptual truth, conceptual elegance and - not least - conceptual simplicity to the:
If someone thinks those are weak arguments, consider how the:
…revolutionized TW!
If I follow your suggestion, there’d be a tiddler called “tags” and it would have a ton of fields whose names correspond to tiddlers, and whose values would be the set of tags assigned to each of those tiddlers. And there’d be a tiddler called “list” and it would have a ton of fields whose names correspond to tiddlers, and whose values include whatever would now be listed in that tiddler’s list field, etc… ?
I can imagine this as a data-structure…
But then the data would not live in the same place it does now, right? Dragging the common tiddler from one wiki to another would not drag any of its field values. Meanwhile dragging the “tags” tiddler would drag all of the tag values from a wiki, regardless of whether those tiddlers exist in the new location (and overwriting whatever data would have been living in the tags tiddler there)?
While I see the appeal of ordinary tiddlers being “simple”… now it’s the fieldname tiddlers that would be quite complicated.
That said, what I do with some of my own wikis displays like what you’re describing. (Open “linkstyle” in the story river — even though it’s not necessarily a tiddler in the JSON — and you see a table with all the tiddlers that have that field, alongside the contents of that field. This effect is created with a view template.) But I would not want that data to live in a tiddler called “linkstyle”.
Or perhaps I’m not understanding your proposal?
Sorry, I was a bit vague.
First the idea only concerns custom fields.
Second, the idea is that if you create a custom fied like so:
foo : hurdy schmurdy burd
then this creates:
title: foo
text: hurdy schmurdy burd
Thus a custom field would really be a transclusion.
I have no firm opinion on whether a custom field without a value should be a missing tiddler or an existing tiddler with only a title.
In a way each tiddler becomes the parent of all its custom fields.
I think this would make it very simple to create stylesheets - seemingly local, i.e directly editable from the tiddler, but they are really a separate stylesheet tiddler. (This would be very similar to the concept I explore in the StyleFields plugin)
It would probably solve the supposed issues with dictionary tiddlers (i.e fields would be used instead)
The concept and use of status tiddlers would become very transparent (you’d use a field).
Every tiddler would be accessible from within every tiddler. Every tiddler gives you full control of everything that you want.
What if I want to use the foo field on 2 (or 200) tiddlers, each with their own value? That isn’t at all hypothetical: the vast majority of my fields are not single-use.
And would each “field” then come with system/metadata fields like created and modified attached? I suppose some people might find that useful for version control, but it seems like a quick route to a bloated file, if foo: A actually necessitates at least 3-4 extra system fields behind the scenes.
And for that matter, wouldn’t this necessitate treating system fields and user fields differently? That feels counterintuitive and like it would add a lot of unnecessarily complexity to filter operations.
Not to mention that I’m sure I’m not the only one who’s inadvertently or intentionally “reused” a little-used system field like author for my own content… I don’t think it would be nearly as simple to distinguish between “custom” and “non-custom” fields as you’re imagining.
I really don’t think most people are using data tiddlers because they’re unaware of the alternatives — especially when out-of-the-box TW makes it much easier to make and work with either fields or tiddlers than with indexes. Sometimes I don’t want 50 separate fields or 50 separate tiddlers, I want a single tiddler with a single purpose and 50 lines. If I wanted to store dictionary-type content in fields or tiddlers, I’d already be doing it! 
So this seems like a “solution” that completely misses the point.
Doh! - you’re right, I’m wrong. That does kill the idea. Thanks. Not sure how I could miss such an obvious aspect. This is/was an idea I got sevveral years ago and this thread [ed: before it was moved] retriggered it but I’m either missing something fundamental from my original idea or it was totally flawed already then.
Not sure how much this would help, but I had two three thoughts reading this.
“what if you nested the tiddler field? like in json, a field within a field.”
and
"what if you had a parent field? i.e. ‘textarea-fields: field-a field-b field-c’ ‘field-b:This //tiddler// contains wikitext’
or, what if you had each field all in one line?
“202508081200:title:tag-a tag-b”
I have no idea if any of that helps anyone, because tbh I’m not sure I can follow the whole discussion as I am right now 
16 hrs rly does a number on cognitive processing.