<tt><font size=2>On further thought, I noticed that "template-based
resource" also describes an AWS::CloudFormation::Stack; and since
those are template-based, you could well describe them as "custom"
too.</font></tt>
<br>
<br><tt><font size=2>Would you consider "nested stack" to also
describe resources of other types that are implemented by Python code (e.g.,
for scaling groups) that creates another stack?</font></tt>
<br>
<br><tt><font size=2>I think the name we are trying to settle upon means
"nested stack that is created by supplying, as the resource type seen
after mapping through the effective environment, a URL reference to a template".
 I really think there is no hope of coming up with a reasonable name
that includes all of that idea.  And in my own work, I have not needed
a name that has that specific meaning.  I find myself more interested
in nested stacks, regardless of the surface details of how they are requested.
 Yes, the surface details have to be handled in some cases (e.g.,
balancing a scaling group across AZs), but that is a relatively small and
confined matter --- at least in my own work; YMMV.  So my new bottom
line is this: (1) for the name of the surface syntax details pick any short
name that is not too confusing/awful, (2) in the documentation closely
bind that name to a explanation that lays out all the critical parts of
the idea, and (3) everywhere that you care about nested stacks regardless
of the surface details of how they are requested in a template, use the
term "nested stack".</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>