When I read
Usability Improvements
- fixed wrapping and wikification of field names in field viewer
in the 5.2.2 Release note, I confess I was hoping it meant we could now take advantage of field names like {{some-tiddler-title}} or <<some-macro-name>>, but it seems I was wrong. Is there some architectural reason why this cannot be done?
If you are suggesting using curly brace’s and <<macro>> braces in fieldnames, even if it worked I would advise against it, because it will confuse the coding and possibly the rendering of tiddlers.
{{!!fieldname}} a fieldname or a transclusion of a fieldname?There are other ways to put code into fields and just placing it in the value of a fieldname is enough to make it safe.
I agree if it is possible to do as you ask, there may be some advantage in some special cases, but on the whole using such methods is likely to confuse most people who come across it, in fact even the original designer. Seeing such values as fieldnames for many would trigger the question “What is broken to cause this”.
However I think there is still a compelling case to have fieldnames equivalent to a tiddler name.
Hi, Can you describe, what you want to achieve?
Right, I can see why this is problematic and probably not worthy of a redesign for most people.
I was expecting the fieldnames would be wikified before rendering,
my issue is that I find it difficult to come up with good names for things straight away, especially since I am still in the process of developing my naming conventions. So when I decide fieldnames (as well as names for tiddlers and macros), and build structure on those, at some point I always find myself needing to change those names for better consistency. The Relink plugin helps when changing tiddler titles, even if it has limitations.
Sometimes, in light of a new need or development possibility, one might wish to modify even some fine naming conventions.
So I guess having transclusion work even at the fieldnames level would help some indecisive users avoiding frequent hardcoding decisions, unless there are already simpler solution that I was still not able to see 
There are quite a few things you can do to address what you want and we could wikify field names but I am confident the approach you were thinking is risky, and more likely to confuse.
I suggest you step back to your initial interest such as assistence naming fields and changing them later if needed. Some examples I have done before such as
Yes, that seems reasonable, thanks.
Just to make sure I got it right, with the 3rd option you mean something like this?
FROM:
tiddler 1 -----------
title: my-tiddler
text: any wikitext... {{!!my-field}} ...any wikitext
my-field: my-value
TO:
tiddler 1 -----------
title: my-tiddler
text: any wikitext... {{my-tiddler/my-field}} ...any wikitext
tiddler 2 ----------
title: my-tiddler/my-field
text: my-value
When I wrote that it seemed clear,
I need to give it some thought; but I expect it will still need options 1 and/or 2 at the same time.
I did just tag some tiddler with #naming-convention … The discussions there may help you to find your naming conventions faster.
To use TW_Tones example
What if the content of some-tiddler-title looks like this
title: some-tiddler-title
{{no-there-is-the-real-name}}
What if no-there-is-the-real-name looks like this
title: no-there-is-the-real-name
some-tiddler-title
What if one of the tiddlers is missing?
Where do we stop? … At level 2 or 3 … How fast should the wiki respond, if 10000 tiddlers use several levels of abstraction?
By the way the 2 tiddlers above will create an endless loop, which would make the wiki unresponsive.