_Originally posted by @herbertmuraro in https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/142#issuecomment-733054387_
While using
--include-nested-stacksoption, when parameters of a nested stack resource refers an output from another nested stack resource usingRef!orFn::GetAttit does not recurse the change detection and worst it shows incorrect information on the nested stack. It'd be better not showing anything instead of informing the replacement of some resources.
In the below example, although there're no changes to the bastion stack, it shows that there're changes and resources will be replaced.

Also, when some nested resource uses Fn::Select(1, ...), it fails the change set creation. I suppose it's because the mappings are created during execution and it's not possible to evaluate them, but in case there're no changes in the inputs it shouldn't mark it for change at all.

.. with that, this feature becomes useless unless there are predefined parameters on the nested stacks.
The same changeset creates fine when
--include-nested-stacksoption is disabled.
CloudFormation functionality itself (didn't seem to match any of the existing categories)
i have so many false changes reported in the changesets, this feature is sadly not usable.
Similar issue exists when a Nested Stack consumes a value from the Systems Manager Parameter Store that is updated by another Nested Stack. Running a Change Set in this case only shows the modification of SSMPS entry, and not the cascading changes that can happen (including resource replacement)...
Most helpful comment
Similar issue exists when a Nested Stack consumes a value from the Systems Manager Parameter Store that is updated by another Nested Stack. Running a Change Set in this case only shows the modification of SSMPS entry, and not the cascading changes that can happen (including resource replacement)...