I just made the same mistake as you, by removing ".dynamic" from all our local packages and updating their Swift Tools versions to 5.4. Except rather than crashing, instead, now when Xcode builds our app, for every Swift package that it decides to build as a dynamic framework, it embeds a copy of it into a Frameworks folder inside every. single. other. package. product. or. Xcode-project-defined. framework. that. depends. on it.
Of course, this "automatic embedding" behavior causes the app to fail app store validation due to multiple copies of the same bundles being deposited throughout the app like easter eggs throughout a backyard on Easter Sunday. WTF.
Like with all the other unwanted, automatic behaviors that plague the SPM/Xcode integration, this also has zero documentation around it, and no way to turn it on or off.
See my post here for details:
I'm 100% certain this problem (described in my post linked above) is the exact same problem that @ferologics is describing, which they have "solved" by writing a shell script to go through their entire app after it's built and remove all the extra copies of frameworks that SPM has sprayed everywhere, and then resign the whole thing.
Our app is 800 MB with 100+ modules... so I find as unacceptable any "solution" that extends our already long CI build times by repeating steps in order to work around an issue that could be avoided by simply not using Swift Packages for anything related to enterprise or business-critical software.
Maybe in Swift 7 or 8, Swift Packages will be able to fully replace Xcode project files without everything caving in on itself. But I've seen enough to now believe that it would be less work to redo our 50+ local packages as Xcode projects than it would be to continue supporting them as Swift Packages.