I agree with Lynn. Use a DDL trigger here that will read metadata to build the changes needed for a table to replicate it.
What I’d do is create a process and some code that duplicates the code a developer writes and moves this to other schemas. then give this to the developer. If he/she can’t do a better job of doing this, then I’d consider finding a new developer. Spending a lot of time on this to program a solution that’s easily fixed by following a process is a little waste of resources.
That being said, if you need all developers to move changes to lots of schemas, I’d think about some text token process that takes a script, changes out the schema, executes it, repeats, etc. This seems like a known process that might be eating up developer productivity unnecessarily if it’s regularlyused.
I’d also run checks to look for missing items that haven’t been moved. That should be a set of relatively simple queries that you can schedule to run and alert someone.