I found my workaround for the unsuitable-for-UI-use fileset numbers may be obsolete as of 2.0.3.12 canary:
This fix is in 2.0.4.2 experimental too, and it might explain how the error message’s fileset number changes, for example if something newer than the bad one was deleted, the UI number of the bad fileset grows lower, however my claim remains that database ID numbers from the Fileset table can’t be put directly in --version because low numbers are the most recent in the UI numbering, but the oldest when looking at the ID field…
@kees-z was talking about complaint numbers, and also database records, so I’m not sure of exact steps, however if the message looked different than the old one (see source), and its number was used for delete but the fileset error remained (see first bullet), then I hope there’s not an issue with the new fileset mapper.