When reviewing the first draft of my current novel, I colour coded the actions and dialog of each character with a unique colour for that character, using the named colours like Orchid, Clover, Plum, etc. I can then review each character for consistency by using the Find by Formatting/Coloured Text/Limit text to colour option.
Unfortunately at some point, most likely, I’m thinking, at the Scrivener 3 upgrade, this ceased to work. Searching for Orchid text returns nothing, and the behaviour if I try the colour dropper is odd: select a paragraph, use the dropper on the colour selector on the toolbar, now I can find that paragraph, but no other. Now select a second paragraph and repeat, now the finder finds both this and the first paragraph, but no other.
So, questions:
Does it sound like I’m missing something obvious or doing something stupid?
Could this be a bug? If so, any hope of a fix in the near term?
Assuming no to both of the above, is there any better way to achieve what I’m trying to do, i.e. tag individual sentences and/or paragraphs to individual characters in such a way that I can review them quickly?
It might be an unfortunate side-effect of ColorSync differences between versions. I don’t think we’ve changed anything deliberately in how the “Orchid” crayon is selected when colouring text in the editor though. Here is what I tried:
- I opened Scrivener 2.9 and generated some dummy text.
- Selected some text, pressed ⇧⌘C and chose “Orchid” from the crayon tab.
- I clicked on the Sliders tab, and then clicked the Gear menu to verify which colour profile was used: “Generic RGB”.
- Closed the project and then opened it in Scrivener 3, upgrading the project.
- Hit ⌃⌥⌘F to open Find by Formatting, set the mode to “Colored Text”, and from the Limit search to color option, again chose “Orchid” from the crayon tab.
- Again, I went over the Sliders tab and verify the ColorSync profile as “Generic RGB”.
- Close the colour palette and clicked the Next button. The sample text created and marked in Scrivener 2 was found.
But I can deliberately test a condition where I’m using a different ColorSync profile and run into a case where Orchid != Orchid. So in theory, although there should be parity between the two versions, it would be possible to run into such a case as you describe. Perhaps an older version of Scrivener used a different profile, for instance, or maybe even an older version of macOS for that matter (seeing as how the colour palette is largely a macOS feature).
To answer your ultimate question: it should be fine, and what you are doing should be the best way to do it. The find by formatting tool has that capability built into it because that should be the best way to work. It is and always has been fragile to minor shifts in colour settings though. There really is no good way around that particular problem. A colour is a number in your computer, and if the editor finds no text marked with that numerical sequence it isn’t going to assume that another number—however close it might be—really ought to be Orchid despite not actually being, in a logical and numerical sense, what it considers Orchid to be.
To be honest, this is why I personally have always preferred using tools like plain-text to tag things, preferably in conjunction with a feature like Inline Annotations to keep the tags hidden. The phrase “NOTE//” is never going to mysteriously shift thanks to some fractional rounding error in the RGB values of a colour (to refer to a much older, 10.6 era off by one colour bug in the text engine), or a change in operating system versions using Device RGB instead of Generic RGB or whatever—it’s just… “NOTE//”. If that gets corrupted then I probably have much bigger problems on my plate than finding the tags. 
And that’s not to say that colour should be disregarded. It’s a powerful tool to the human eye, and I do use colour in my inline annotations to denote type. I just do not rely upon that information as my sole source for semantic tagging. If the hue of blue I use for post-compile proofing notes shifts by a slight amount, I don’t really care. All that matters to me is that it is blue-enough and has “PROOF//” printed in text.