Currently after all resources are generated, ones specified by user (defined at resources.Resources) are deeply merged to it:

It's unsafe operation, as it unconditionally merges all arrays and objects, producing broken configurations in some scenarios (e.g. merging two independent Fn::Joininstructions, as reported here #6569). Also it doesn't apply any validation so technically two resources of very different types, if they share logical id, will be merged silently.

Proposal for new approach

1. Restrict resources for CF Resources section.
2. Accept newly introduced user resources (not extensions) at resources.additions. Use direct (Object.assign like) assignment to apply them on Resources, but error if given resource was already generated by the framework (do not silently override)
3. (Already implemented at feat: Support resource extensions #7352) Accept extensions at resources.extensions for definition of resource extensions which should be applied to resources already generated by the framework. It should be intelligent (deterministic) in sense that:
   • Properties should be merged flat way (so framework generated given property is listed, it'll be overriden by user resource completely)
   • DependsOn should include both items, those listed by framework, and those indicated by user
4. Support addition of other CloudFormation template properties at top level cloudFormationAdditions, where each property should be supported individually as follows:
   • description - Assign as is to result template
   • metadata - Assign each section directly, but error if metadata of given name already exists
   • parameters - Assign each definition directly, but error if parameter of given name already exists
   • mappings - Assign each mapping directly, but error if mapping of given name already exists
   • conditions - Assign each condition directly, but error if condition of given name already exists
   • transform - Add listed macros to the list, but prevent the duplicates
   • outputs - Assign each output directly, but error if output of given name already exists

Above can be implemented without breaking current behavior. Ideally after having that in, we should mark current behavior as deprecated.

PR's welcome (each section can be tackled individually with different PR)