Thank you Eric, both for taking the time to explain, and explaining it SO CLEARLY!
In over 2 years of using TiddlyWiki, I don't believe I ever properly understood this behaviour of macro definitions.
It was like a "hit or miss" game --- so happy when it worked --- back to the drawing board when it didn't, without knowing why.
By knowing this concept, it quickly becomes clear WHY a certain $macrocall is NOT to right way to proceed.
It also makes me immediately see a better solution, like below:
<$set name="SET-related-tiddlers" tiddler=<<tid>> field="list">
SET-related-tiddlers= <<SET-related-tiddlers>>
4. WORKS!: <$macrocall $name="test" list-tids=<<SET-related-tiddlers>> field="list" />
</$set></$set>
There is still a little confusion about "parsing" and "rendering."
From what I (probably mistakenly) understand, a <<macro>> that is used as parameter in a <$widget parameter=<<macro>>/> - the macro is "parsed" but not "rendered."
From what I understand (in a limited way & paraphrasing from Jeremy) of parsing, is that, - this is the basic scanning of a block of text to find bits of wikitext syntax - (e.g. finding the {{!!tidd}} transclusion). The result of parsing is a tree that we then use to construct the render tree.
Now the <<macro>> as the $widget parameter simply gives to the $widget a parameter of replaced text for its $param$ & $(var)$ etc. values. That's it.
The widget's "parsed" code sits on the "render tree." Parsing here means the WikiText for expanding has been kind of "flagged" - awaiting a refresh signal - when it will then be "rendered"?
When its time for "refreshing," this is the time all those "flagged" parts are "rendered" - which I believe is turning it into the appropriate HTML/CSS - and assigning it to the proper place in the
DOM (Document Object Model -- html elements & their properties etc.)
nodes ( a cancerous growth of html injected by javascript into existing
html elements).
The << macro>> that sits as a parameter in a $widget has been parsed (flagged for expanding on a refresh) but still is not expanded (rendered into html). Thus when another $widget2 accesses $widget, it gets this unexpanded (unrendered - un-refreshed) value - that leaves so many confused and frustrated!
When there is some change that affects a part of the "render tree" where all the "parsed" stuff is patiently waiting - it's time for a "rendering." The affected parts of the "render tree" are refreshed (values found and turned into html etc.).
This happens quite often when editing a tiddler with the view pane switched on - but until something is typed that affects the "render tree" - for example that <<macro>> that sits in the open WikiText (in the text field of a tiddler?), those affected patiently waiting widgets etc. on the "render tree" - get "rendered" - since as soon as typing that WikiText macro completed, a signal that some change has happened affecting the "render tree" calls for the selective refresh (selective rendering of the parts of the "render tree" affected by the recent change).
Now that I have made a complete mish-mash of trying to explain how I understand what is happening - I hope I can entice you to enlighten me!