Yup, without short ids being ambiguous, this problem wouldn't be here.

I think it'd be ok with me as well to ignore this issue, IF users were educated
to always use fingerprints instead of the keyid, but as of now unfortunately
most people still seem to prefer them.

I think that the gpg --list-keys output is supposed to be consumed by humans,
not automated tools, right? If so, it might be helpful to switch its default
representation to show fingerprints and not keyids. (Also, I find it a bit
confusing that the default fingerprint representation for gpg, that is: 4
hexdigits separated by spaces is not supported by other tools like apt-key, but
I guess this should be raised as an issue to them).

Moreover, --delete-key always prompt before deleting, so prompting twice
wouldn't be risky... and I just realized from the gpg manual, for --delete-key:

"Remove key from the public keyring. In batch mode either --yes is required or
the key must be specified by fingerprint. This is a safeguard against
accidental deletion of multiple keys."

So, apparently, according to the manpage, --delete-key is supposed to delete
multiple keys.

gpg2 --help instead shows a --delete-keyS command... but that command
doesn't delete multiple ambiguous keys either.

I framed this bug report with the user expectations for an invariant, not as a
bug of the --delete-key or --recv-key command, since it could be fixed
either way, so I don't have a strong opinion in the direction to take from here

a couple of examples I'm aware of:
A56E15A3
70096AD1

Thank you