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.

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.

A common mapped database is essentially the end result. The question here is not asking about the end result, but rather how we get there for an already existing system. Say we have a customer with an instance that already has a good deal of custom code across multiple databases. How do we move all of this code spread across multiple default routine databases to a single location so then all Namespaces can use a mapping to access it in one place?

Glad you asked, I would hope (depending on available tools/API) that there would be measures I could take to detect collisions and in that case do not merge the contents of that database with an informative message to the user that contents will need to be merged manually.

Apologies for the late reply! We hook into OnAfterCompile and check if the compiled item is a Business Host class. If so, this triggers a search for any config items and triggers a restart if they are instances of that class. The reason this is only available to IRIS 2019.4 and up is I believe this is when the temporary stop and start functionality was added as we did not want this feature to alter the Production Definition.

This is exactly what I was looking for, did not realize this was a method as I was instead looking at the private position property. Thank you!

See my reply to Ben, below. Unfortunately it seems the first process is not necessarily correct for instances with an upgrade history from Caché to IRIS.

Thank you for asking this, Ben. The superserver is not the first process and comes after auxiliary write daemons. I also found multiple cases for instances that upgraded from Caché to IRIS where the first process uses cacheusr but the superserver uses irisusr. So this will not work. I think we may be stuck with looking for the superserver process.

I found no direct documentation but got some information from the method documentation of the NextProcess class method in %SYS.ProcessQuery:

https://docs.intersystems.com/iris20243/csp/documatic/%25CSP.Documatic.c...

So, it seems passing an argument works like $order on the list of running processes with the caveat a halted process is treated like $zjob("") and returns the first process id in the list. I think this will do the trick, thanks Alice!

@Brett Saviano 
I do suppose $System.OBJ.Load and LoadDir from a terminal in VS Code is the next best thing until my work involves UDL exported routines. Thank you for the quick response!

I had forgotten how the MPP works. Then outside of copying the compiled expression I cannot use macros in a break from a terminal session. Thank you!

I am specifically referring to using terminal/command line. Otherwise, the debugging tools offered by Studio or VS Code would be a decent solution.

I have found a tentative solution in checking the compiled .int code and copying the resulting lines from there into terminal. It still would be helpful to know if there is a way to access the individual macros directly from within a break.