Here are some thoughts:

• Write Source Control Hook that implemets OnAfterSave method and checks there (or maybe some other entry point). There are several sample source control hook classes, check them out.
• Use ^rINDEXCLASS global (key - class name in uppercase) - it contains some basic information such as modification time (1st position) and hash (13th position). You can monitor it and if time or hash changes then record the new class version.
• Use lock table to see what classes are currently being edited
• Use $$$defClassKeyGet macros (see %Dictionary.ClassDefinition/%Dictionary.CompiledClass definitions, they use these macros a lot) to get info about modification time/hash and the changes themselves
• %Compiler.UDL.TextServices to get the class text

I would have done it like this:

• Background process monitors ^rINDEXCLASS global
• Upon finding changes get the current class code via %Compiler.UDL.TextServices class,  GetTextAsStream method
• Write this information into your own class (classname, timestamp, user, classtext, diff, previousversion)

Modification of system classes is not a very good idea:

• They are lost on update
• User may not have access required to install these changes

That being said, the best solution in my opinion is to setup your critical/production systems in such a way, that developers do not have direct write access to them. Each of the developers have their own environment where they can do whatever and then commit it to source control system. Continuous integration solution (or one developer or a script) then uploads the code (after it passes the tests) to the production server. There are several source control/continuous integration systems available for Caché.

It is a good idea that a change can only be done via source control commit. All other changes simply should not exist.

There is a beforeunload HTTP event which is fired when the window, the document and its resources are about to be unloaded. Handle this event in your js code and from there you can send an HTTP request to a server (I usually use GET /webapp/logout), which would do something like this:

ClassMethod logout() As %Status
{
    #dim %session As %CSP.Session
    set st = %session.Logout(1)
    set %session.EndSession = 1
    return st
}

Index NewIndex1 On PropertyD(ELEMENTS);

Documentation.

 I'd also love to see the web application's properties programmatically, if possible (such as the physical files path).

Use Security.Application class directly, or preferably via %Installer manifest.

but I honestly don't know why it's choosing that web application over the default of /csp/default-namespace

Uncompile and compile ZEN classes after setting default web application. Or you can try to set HOMEPAGE parameter in the application class.

My question is, if we go to using Group By ID (which is currently null) in the web application, will this fix the sharing of %session Data? (This is why I have to make sure I'm editing the correct web application!)

If the user opens one web application in two tabs, they would be sharing a session (and namespace). Group By ID would only help if you have N different applications and would specify N different values for Group By ID property. In that case, they should use N different sessions.

Finally, we have a web application for each namespace; will we need the Group By ID for each application defined for each namespace, and should it be the same ID?

Depends, if you want to share %session or not.

Add init parameters:

set htmlSnippet = "<h1>Hello</h1>"
set regex = ##class(%Regex.Matcher).%New("<[^>]*>", htmlSnippet)
set plainText = regex.ReplaceAll(" ")
write !,plainText

Then you need to specify MODE attribute as LOGICAL for that cspbind property. Documentation.

Sure, execute this in a terminal to open a new terminal for an instance named cache:

do $zf(-2,"cterm.exe /console=cn_ap:cache")

$ZF(-2) docs, cterm docs.