I know this doesn’t fix the perceived injustice part, but as a way to get on with getting useful work done, why not use an observation field? Fields don’t have the same functionality that an annotation has, but for most intents and purposes, they get the job done.
One advantage that a field has over an annotation is that you can’t correct an annotation that someone else set. Other users can only downvote the incorrect annotation. With a field, anybody can change the value. That means if it is set incorrectly, it can be overridden (of course, that cuts both ways, but I’ve rarely see anyone alter a field value that I have set).
You’re probably already aware of it, but there are already 2 different versions of “Bird Life Stage” fields defined. If neither one offers a range of possible values that suit your needs, you can create another version.
One downside to fields is that some observers set their preferences to block others from adding fields to their observations.
Again - there’s a field for that. If you don’t like one of the various ones that already exist, you can create a new one that meets your needs. For your example, you could add the following fields (which already exist in iNaturalist):
Insect life stage: Adult = Yes
Insect life stage: Nymph = Yes
That’s two fields. A bit tedious if you have to type them in, but you can always use the Metadata tool to create shortcuts that add these fields with a single key stroke. Another (somewhat cruder) way is to add some kind of freeform field and type in “observation contains two life stages - adult and nymph”.
These options work for me because I am usually both the source and sink for the fields in question. These are essentially conventions I’ve made with myself. I (mostly) don’t have to worry about somebody doing it wrong. I try to make them as straightforward and intuitive as possible so that other people can use them in the same way, but at the end of the day I’m entering the information when I review the observation so that it’s there for me to harvest at the end of the season. If you’re not the intended “audience” for the information, it’s hard to know what the best way is to enter it. One approach is to ask owners of projects that are somehow related to the taxon in question (“How do you guys want me to annotate something like this?”), or just look for how other observers have handled similar situations.
Since you say you have no intention of doing annotations, I’m not sure why you’re agonizing over it. Many projects have set up their own guidelines for how they want various things annotated. Unfortunately, they rarely seem to make any effort to re-use existing fields. Everyone creates their own and mutually incompatible annotation/field conventions. That’s one advantage of annotations - there’s an element of enforced conformity. With fields, everyone can do whatever they want and it shows.
Pro-tip: It is often helpful to use a field that mirrors an annotation. In cases where someone has set the annotation incorrectly, you can apply the corresponding field with the correct value (vs trying to get the user to change their incorrect value). It also allows you to apply whatever options you feel are missing from the annotation. For example, the “sex” annotation only allows Male, Female and Unknown. But the “sex” observation field allows an additional value - mixed, which is useful for observations that contain both sexes. I use the sex field for these cases, and for cases where the sex annotation is set incorrectly. My software that harvests observation data gives precedence to whatever value is in the sex field over the sex annotation. In case where I’ve added the field because the corresponding annotation is wrong, it could theoretically serve as a prompt to whoever set the annotation incorrectly. I don’t know if this has ever actually happened. I suppose I could check to see if there are any cases where I’ve added the field and the annotation has the same value - that would be a clue that at some point, the annotation must have been corrected, but I’ve never bothered checking.