Please describe the problem.
Current syntax of dead online at git annex dead [repository ...] [--key somekey ...] says
git annex dead [repository ...] [--key somekey ...]
which is also incorrect rendering I think since it is
[d31548v@ndoli tmp]$ git annex dead --help
git-annex dead - hide a lost repository or key
Usage: git-annex dead [[REPOSITORY ...] | [--key KEY]]
so it is EITHER to announce REPOSITORY or a KEY.
Naive/new/quick users, since many annex commands take file paths as arguments could provide dead with both - repository and local paths, e.g. git annex dead here */*.nii.gz or alike. But then annex proceeds with marking here dead while then erroring out on paths:
(datalad-dev) [d78092t@ndoli 1080_wasabi]$ git-annex dead here sub-SID000743/ses-01/func/*.nii
dead here (recording state in git...)
ok
git-annex: there is no available git remote named "sub-SID000743/ses-01/func/sub-SID000743_ses-01_task-hyperalignment_acq-mb8_run-04_bold.nii"
which is correct/expected behavior given the fact that if RTFM then those are to be taken as repositories.
But I wondered if may be git annex could/should become more "protective" and fail early if any of provided repositories is "not available"?
It's not repository OR key, dead can be used with multiple keys, multiple repositories, or a combination of keys and repositories.
(The automatically generated --help does not make it clear that --key can be used repeatedly, but the man page does and is correct. I guess that optparse-applicative --help does not try to distinguish between options that can be repeated vs options where a later option overrides an earlier one.)
I think arguably dead should be able to operate on paths too. If a user has lost the only copy of a file, but not deleted the annex link, it would be easier to use the path than looking up the key.
Since dead refuses to do anything when there's still a recorded location for a key, there would not be any risk of operating on files whose data has not been lost.
(There would be some ambiguity, eg "." can refer to both the "here" repository, or all files in the current directory. For that matter, the name of a repository could also be ambiguous with a filename.)
Making it reject "here" when provided with additional parameters that are not repositories would conflict with such a change.
I realize that it's annoying to make a mistake like you made, but it's also not hard to undo it once you realize that you've made "here" dead.
A better guard against that mistake might be for it to refuse to mark the current repository as dead, since it still exists. But there are probably workflows where a repository gets marked as dead just before
rm -rfof it, which that would break.