I'm trying to understand the purpose of this, because it's still a little fuzzy for me.

Are you thinking of running the necessary python code on evermizer.com/apbpatch ?
Or is this just so you can give an error message like "This patch isn't supported" ?

While if someone gives you a KH2 APContainer, you can instead give an error message like "This isn't a patch"
because it doesn't have the procedure defined?

This change serves multiple purposes:

• if someone wants to implement, say, custom+zillion in their alternative Patcher, they can
• if it's custom, but the alternative Patcher did not implement that specific game, then you get a proper error by default "Custom patch for {game} not supported"
• if a world switches between custom and APPP or custom and APDelta, it's trivial to detect that Patch and AP are incompatible
• if an APPP or a custom APPatch includes a file called "delta.bsdiff4" or "*.zpf", it would be impossible to detect compatibility issues, by bumping the compatible_version we fix that.
• it is now possible to differentiate between APPatch and APContainer (i.e. "This is not a patch" and "This patch isn't supported" messages)

I do not plan on implementing Zillion in APBPatch, by the way. If we ever get a proper wasm target for python one day, it would be possible by providing a hook from JS that "installs" AP code on demand though.

AP released the procedure patch system and I think the description here is correct, so merging for future reference.