To me, the most impressive fact about InterSystems is that it doesn't
hide or deny its roots or reject its history, and keep its backward compatibility.

I remember a customer who had composed and used an incredible complicated
program to create knitwear patterns with his equipment for over 30 years without change.
When he migrated to IRIS it was running perfectly without changing a single bit.

This still impresses me more than all the new language features
that force me to adjust versions as an ongoing challenge.

As you say, IT SEEMS.
And I used it quite intensively. until it was blocked with <PROTECT> by 2024.1
see this Discussion  WARNING: Bug in IRIS Native API
It was intentionally https://community.intersystems.com/post/warning-bug-iris-native-api#comment-282334

Some documentation was adjusted, but not the internal Class Reference
https://docs.intersystems.com/iris20252/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25Net.DB.Iris#Function

It was quite some effort to rewrite all my 9 Native API examples
for Py,. JS, ObjectScript to make them work again

3 variants come to my mind

  1. writing to ErrorLog  Do LOG^%ETN()
  2.  write to Systrem message.log
     set %evgeny=$io
     open 1 use 1 write !,"Was in my REST code",! close 1
     use %evgeny
  3. If you have a terminal session  LOCK  ^%EVGENY --- And into your code, add this simple loop 
  4.  for  LOCK +^%EVGENY QUIT:$TEST   HANG 0.5
    Now your method loops, and you can attach with any external debugger. Releasing the LOCK from Terminal does the "un-freeze"

I've been offering my reports on reviews for more than four years now,
as a personal service to the DC community, to show recent reviews.
And this covers any new review I can detect, not just add-ons to my own 700+ positive reviews
I started it long before the quality reports you mention were even proposed and implemented.

And even at my advanced age, I'm not willing to leave my audience in the lurch
until I'm explicitly forced by DC+OEX managers with a reasonable explanation.

In addition, the quality reports you address have neither a selectable overview
nor any kind of summary or view of progress. 

Release notes version 1.0.0

Based on the very positive feedback, I have added a new functionality.
It is now possible to also take a snapshot from a remote system.
The only requirement is to append an URL-Parameter formatted like this:

?SERVER=IP-Address[:SuperServerPort[:Username[:Password]]]

defaults: port=1972 user=_SYSTEM pw=SYS
Example 

http://localhost:42773/csp/user/ZX.dbdash.cls?SERVER=192.168.0.11:11972:SuperUser:SYS

From Class Docs:
• classmethod ExportAllClassesIndividual(dirname As %String = "", qspec As %String = "", ByRef errorlog As %String, Charset As %String = "", Package As %String = "*", SubDir As %Boolean = 0) as %Status

Export all the classes as individual XML files to a directory.

This method loops through all the classes, exporting each one as an individual XML file named after the classname to the directory dirname. If you specify a Package, then it exports only this package. If SubDir is true,, the method exports sub-packages as subdirectories.

Now the directory is your list of classes and equal sizes of files 
might most likely mean identical content. Or you do a text compare

You are right. $system.OBJ.Export~whatever is oriented to the Namespace

BUT:
There still seems to be no limitation to map a specific database file
to more than 1 namespace. e.g. USER and MERGER (here Read Only)
Then $system.OBJ.Export~whatever takes what it finds in MERGER.
It's quite a dirty approach and only meant for READING the code, therefore, ReadOnly

In any case, it's safer just to copy the (most likely static) DB of interest
and use it in MERGER