How do I delete secret subkeys correctly?

[Matheus Afonso Martins Moreira]

I had some revoked subkeys that I was not going to use anymore.
I thought it would be a good idea to delete their secret keys,
so I used the gpg --delete-secret-keys command to do it.
I ended up accidentally deleting all my keys instead,
including my primary key.

I'm trying to learn from my mistake but I don't understand how or why
this happened.

I was able to reproduce what I did.
First, I generated a primary key and a subkey:

    $ gpg --batch --passphrase '' --quick-generate-key 'test key' rsa4096 cert 0
    # Generated primary key D7D79C32883EA862C586881DA52099E0E7EB77A5

    $ gpg --batch --passphrase '' \
        --quick-add-key D7D79C32883EA862C586881DA52099E0E7EB77A5 \
        rsa4096 sign 0

    $ gpg --list-keys
    pub   rsa4096/0xA52099E0E7EB77A5 2019-04-10 [C]
          Key fingerprint = D7D7 9C32 883E A862 C586  881D A520 99E0 E7EB 77A5
    uid                   [ultimate] test key
    sub   rsa4096/0x20AA2F4F7A28CD01 2019-04-10 [S]
          Key fingerprint = 9CAE 802D A78E 4624 BD8F  88FE 20AA 2F4F 7A28 CD01

Having generated a primary key and subkey,
I asked gpg to delete the subkey by specifying its fingerprint.
However, instead of operating on the specified subkey,
gpg asked me to confirm the deletion of the primary key!

    $ gpg --delete-secret-keys 9CAE802DA78E4624BD8F88FE20AA2F4F7A28CD01

    sec  rsa4096/0xA52099E0E7EB77A5 2019-04-10 test key

    Delete this key from the keyring? (y/N)

I admit that I failed to check the fingerprint reported by gpg
before confirming all three prompts, including a graphical pop-up.
However, I did double check the fingerprint I gave as argument.
In my understanding, the program decided to operate on a different key.
I specified the subkey but it acted as if I had given the primary key instead.

It was suggested that I append an exclamation mark to the fingerprint.
Indeed, the manual does seem to support this suggestion:

> an exclamation mark (!) may be appended
> to force using the specified primary or secondary key
> and not to try and calculate which primary or secondary key to use.

When I tried it with new keys, it did not seem to have any effect.

    $ gpg --delete-secret-keys 5B139477AE36C2F5D03C29E6920FD2FB0019253E!

    sec  rsa4096/0x8A1C31D584422F7A 2019-04-10 test key

    Delete this key from the keyring? (y/N)

gpg still tried to delete the primary key instead of the specified subkey.

It was also suggested that I use the subkey's ID instead of the fingerprint.
I generated new keys, tried it and it did not work either.

    $ gpg --delete-secret-keys 8395C88AD6549DEE

    sec  rsa4096/0x076968E9FF7991BC 2019-04-10 test key

    Delete this key from the keyring? (y/N)

    $ gpg --delete-secret-keys 8395C88AD6549DEE!

    sec  rsa4096/0x076968E9FF7991BC 2019-04-10 test key

    Delete this key from the keyring? (y/N)

gpg always deletes the primary key and all subkeys,
no matter what input I give it.

I am using GNU Privacy Guard 2.2.15 on Arch Linux x86_64.
I don't want to make this kind of mistake again.
Am I using the program correctly? If not, what is the correct way to do this?
Is deleting subkeys something I am not supposed to do?