This took a while to track down - sorry for the delay.
The machine which was being upgraded had a non-functional shim in place instead of rpm. This had been done to satisfy a hardware-vendor provided firmware upgrade, which would not work unless an rpm executable was found on the system (despite the fact that the firmware upgrade did not use rpm).
dkms preferentially uses rpm (even on Debian) to try and determine the architecture of the running system (instead of other methods such as `uname -m` or `dpkg --print-architecture`).
dkms uses the architecture which it has determined to store compiled modules at /var/lib/dkms/$module/$version/$kernelver/$arch/modules/
This use of a non-functional rpm resulted in dkms setting its internal architecture to the empty string. This made dkms work correctly whilst installing modules (storing the resulting modules without the $arch path componenent) e.g. to /var/lib/dkms/ddcci/0.3.3/5.10.0-14-amd64/module/ddcci.ko and also detect the presence of already installed modules, but also resulted in it silently failing when asked to remove modules.
If this is considered a bug, then it would seem reasonable for dkms to treat it's internal architecture variable being set to the empty string to be an error condition, and to exit and/or to fall back to using other methods of determining the architecture (which it does on Debian systems which don't have an rpm binary installed).
