Yes, Your Honor, the defendent was found exceeding the posted limit of one extended metaphor per message… 
There are a lot of operators. It takes a long time to learn them all, or at least longer than I’ve been able to spend in the last few years.
And as seen in the conversation here, sometimes individual operators do multiple things, either by default, as in removeprefix or via configuration, as in trim.
There are various tools worth investigation. I assume that if you’ve been doing this a while, you’re at least passingly familiar with WikiText, but he others may be new to you.
It’s a combination of HTML markup and a ListWidget. If you’re familiar with HTML from another context, it works pretty well the same inside TW tiddlers. It’s difficult (at least for me) to get WikiText Tables to work with lists, so I usually end up with HTML for them.
How I work
Typically, I would start with a <<list-links>> macro to make sure I have the filter I want to use correct. Here I already tested the filter in the Advanced Search > Filter tab, but I still rechecked it here. So my first step would be:
<<list-links filter:"[all[shadows]prefix[$:/language/Docs/Fields/]]" >>
That displays a bulleted list of tiddler titles, and looks correct, so I mechanically change that to a <$list> widget like this:
<$list filter="[all[shadows]prefix[$:/language/Docs/Fields/]]" >
<$link/><br/>
</$list>
Note that we now have opening and closing tags for the <$list> widget, and we’ve moved from the macro shortcut syntax of <<name ...params >> to the more HTML-like <name ...attributes> ...content </name>, where name uses the tiddlywiki convention of starting with $, so <$link ...>...</$link>. Also note the minor annoying need to switch from filter: to filter= as we switch from the macro shortcut syntax to a list widget. (This might be going away sometime soon.) Finally, we have some content that will be created for every value our filter creates. Here I use another placeholder, just to make sure my list widget is acting correctly. I include <$link />, which will create a link to the current title, followed by <br/> to add a line break between them.
When I’ve confirmed that the above is working correctly, I replace the content with the markup for my table row, and wrap the whole thing in <table> tags and add a header row. (I often skip this step, but it can help me avoid making too many changes at once.):
<table>
<tr><th>Name</th><th>Description</th></tr>
<$list filter="[all[shadows]prefix[$:/language/Docs/Fields/]]" >
<tr>
<td>name will go here</td>
<td>description will go here</td>
</tr>
</$list>
</table>
I fill in with the actual content I want for my table cells, generally one at a time, saving and confirming after each change. First I want to start with the current tiddler and remove the prefix to leave just the name:
<td>{{{ [<currentTiddler>removeprefix[$:/language/Docs/Fields/]] }}}</td>
for name is almost fine, but I don’t want it to be a link, so I wrap it in a text widget
<td><$text text={{{ [<currentTiddler>removeprefix[$:/language/Docs/Fields/]] }}} /></td>
That works fine, and now I want the description:
<td><$text text={{{ [<currentTiddler>get[text]] }}} /></td>
Et Voila!, we have our table:
<table>
<tr><th>Name</th><th>Description</th></tr>
<$list filter="[all[shadows]prefix[$:/language/Docs/Fields/]]" >
<tr>
<td><$text text={{{ [<currentTiddler>removeprefix[$:/language/Docs/Fields/]] }}} /></td>
<td><$text text={{{ [<currentTiddler>get[text]] }}} /></td>
</tr>
</$list>
</table>
This is my usual process, and most of it is mechanical and quick. Usually finding the exact filter expressions for the list – and sometimes for extracting the text cells – are the only time-consuming parts. This one took me maybe five minutes to create… and a lot longer to write up here.
Note that that bare-bones list made with <<list-links ...>> may last a good while. It’s perfect temporary filler for something I want to come back to later but don’t want to distract me now.
Replace the “FIRST-FIELDNAME-OLD” and “-NEW” in the code with the actual first field’s old and new names, and so on for additional field names.
)
… I’m pretty sure I’ve got that now 
and I’m even more sure that it would work as I already achieve something similar with tags, having names such as those in the example that I gave in parentheses, earlier.