Thanks for the tip, I went back and took a closer look at those Python-scripts.
I had tried fiddling with the SCPI control panel in Ultra Sigma before, but never managed to get the :SYSTEM:OPTION:UNINSTALL command to do anything, it just ended in a timeout.
I saw now that one of the Python-routines hammers the SCPI-commands up to 30 times, so that got me thinking about the control panel again.
I started Ultra Sigma and switched the control panel to Advanced Mode, and changed the timeout setting to 10.000ms, but still no dice with the uninstall-command.
Another thing I noticed was that one of the Python-routines does an expect-like check of the "*IDN?"-prompt, while the other does not.
Now I accidentally discovered (duh..) in the control panel that you can actually backspace away the *IDN? part, so I did it, and ran :SYSTEM:OPTION:UNINSTALL without any "prompt" ahead of it.
It took a few seconds, but this time it worked!
The scope made a loud CLICK noise and lit up both channels, and my DS2102 now identified itself as a DS2072! O0
I powercycled and tried installing my DSAZ-code through SCPI, but that still wouldn't work, even with the special settings in the control panel.
So I entered the DSAZ-code through the on-screen keyboard as I had originally done, and it worked.
After another powercycle I had a DS2202 with all options enabled again.
The purpose of my little exercise was that I had originally used a DSAR-code, which enabled 100M in the Options-list.
Later when the complete code-matrix was revealed to us in the thread, I entered the DSAZ-code, and this combination resulted in the Options-list showing both 100M and 200M, much like the DSA9-code I assume.
With the help of another DS2102-owner here at the forum, I was able to surmise that the 100M-option should NOT be displayed when activating a DS2102 to DS2202, so I wanted it gone.
Because who knows what could happen down the line...
First of all it's a clear sign that the options have been tampered with, and I suppose that discovering this state in the instrument could be targeted by Rigol in future firmware-updates in the coming antihack-war.
Not to mention that it's an invalid state in the instrument. I've worked enough with code monkeys in my career to know that it only takes a single if-clause that checks for the bandwidth-options in the wrong order to send me down a code path where I get 100M precision instead of 200M, or whatever else undefined behaviour that could result from something like that.
Maybe I'm too paranoid about this, it's quite possible, but I prefer reducing the risks of possible problems.
Thanks again!