To clarify: I would like to see the targeting of keys be unified.
I see the following options:

1) Consistently support both fingerprint and uid to specify a target key.

This means that all of these will work

gpg --quick-add-uid foo@gmail.com "Name <bar@gmail.com>"
gpg --quick-add-key foo@gmail.com rsa4096 sign 2y
gpg --quick-add-uid $FPR "Name <bar@gmail.com>"
gpg --quick-add-key $FPR rsa4096 sign 2y

This exact behavior seems to be already implemented for --quick-add-uid. If there is ambiguity it will give an error.

gpg: key "foo@gmail.com" not found: Ambiguous name

This would need to be implemented for --quick-add-key in the same way. Possibly in other places, too.
Also the documentation and usage information would need to be updated.

2) Consistently use fingerprints only

This means that only the following will work:

gpg --quick-add-uid $FPR "Name <bar@gmail.com>"
gpg --quick-add-key $FPR rsa4096 sign 2y

For this the documentation need be changed for --quick-add-uid and the use of uids should be deprecated.
This means there is no possible case of ambiguity anymore. But this also means that access to the fingerprints must be made more accessible. While the use of --status-file and awk in this case works, it's very clunky. Especially when targeting not freshly created key this would require parsing stdout.

Ideally the create operation would return the fingerprint in a way that it can be consumed without further parsing.
Listing of all key fingerprints and fingerprints just matching a uid would need to be implemented, too.
The exact interface would be up for discussion. This would only be a start:

# creation
$ gpg --print-fingerprint --quick-gen-key "Name <foo@gmail.com>" rsa4096 cert,sign never
E1F122A3ED115448C863298C85AEC379CF3E598B

# unique
$gpg --fingerprint foo@gmail.com --print-fingerprint
E1F122A3ED115448C863298C85AEC379CF3E598B

# ambiguous
$gpg --fingerprint foo@gmail.com --print-fingerprint
E1F122A3ED115448C863298C85AEC379CF3E598B
C32C7ADB10A7580CCAACD04D2D6BED697ECF510D

# all
gpg --fingerprint --print-fingerprint
E1F122A3ED115448C863298C85AEC379CF3E598B
C32C7ADB10A7580CCAACD04D2D6BED697ECF510D
D015FCE796DEB6D2D40DCAACC0857A01BDA7C232
``

I am not sure wheat I understand your request. --quick-add-uid takes a fingerprint as first argument you _may _ use a a user-id instead but that is for consistency with all gpg commands. Using the fingerprint is always highly suggested.

Sure we can print a new status line with the fingerprint of the created key but that does not make much sense becuase you already get this via the current status output. Printing the fingerprint of the created key on stdout would of course be possible but that would be the start of a new complementary machine inetrface which is IMHO not a good idea. Why not

$ gpg --quick-gen-key --passphrase '' --batch --status-fd=1 test@example.com \
   | awk '$1=="[GNUPG:]" && $2=="KEY_CREATED" { print $4 }'

which prints the fingerprint and only the fingerprint to stdout.

From the man page:

--quick-add-uid user-id new-user-id
--quick-add-key fpr [algo [usage [expire]]]

1. It does not mention that --quick-add-uid can also use a fingerprint.
2. --quick-add-key requires a fingerprint (which is a different behavior compared to --quick-add-uid)
3. Using --status-fd=1 is for --quick-gen-key somewhat acceptable, it does not solve the problem of getting to the fingerprint in a machine readable way when you want to lookup uid -> fingerprint. (for using --quick-add-key outside of the context of --quick-gen-key)

You completely ignore the fact that --quick-add-uid and --quick-add-key are not consistent.
It's not clear why one should require a fingerprint and the other allows the kind of "user-id" you just described.
That was the main point of this issue.

And FWIW: an inconsistent UI/CLI should be treated as bug - not as a feature request.

The command line is an API and we will never break an API without a very good reason. If you didn't like that API you should have noted that on the devel mailing list years ago ;-)

I should have :) Thing is - a fix could be made in a backwards compatible way. So I don't really see your point.

We do have a history of extending the API, no?

it looks to me like @tcurdt is asking for quick-add-key to take a user-id, which is an extension of an fpr. that would make it consistent with quick-add-uid

Right, but requires extra code. The --quick commands try to reuse existing code and, iirc, that is the reason why a user id is accepted for --quick-add-uid.

(Wasn't it you who always suggested to use the fingerprint .-)

@werner That begs the question: why can't quick-add-key re-use the same code that quick-add-uid is using?