Very clever! Yes, I think I could create a Namespace that points to just the routine database of interest, merge over contents to target (since everything from that MERGER Namespace is desired), use this intermediary for each database of interest, then clean up at the end. Per Eduard's point above regarding conflicts, is there any way to pre-empt conflict using such tooling? If 2 databases have a class of the same name defined, how can I prevent clobbering the contents merged from the first database when I merge the second? Even if it is a conservative approach of failing to move code if there is any overlap, I think that would be preferable to overwriting existing code.
Tricky bit there is forming that list. DataMove seems to be per source Namespace rather than per source database. Is there a good way to get a list of all relevant contents from a specific routine database? This would be all classes, mac routines, int routines, projects, and more, but only those that are defined in the default routine database with care to not move mapped items.
I could do exports of contents from each database, accumulate these in a common directory only adding files if not already present, and then load everything in from this directory at the end. I was looking to avoid this approach if possible since I really just need database contents to move locally but if this needs to turn to OS file system exports, then that is a valid approach. I just need to be sure to export all of each item type that is present in the routine database (classes, routines, projects, etc) and import them using their respective APIs. Should a category of item that is stored in a routine database be added in the future I would need to account for this and explicitly add it to the list.