Right. While to me, it's asking "does this value match the pattern FOO"? Again, the Glasgow Haskell folks have implemented this very same capability (much-extended), and they call it a feature: pattern synonyms. I've always assumed our consts were in the same spirit.
And I mean... why would we expect something used as a pattern to be interpreted as anything other than a pattern? I can see how someone who has not had much exposure to pattern matching might fall back on intuitions about == for a time, given that the two often coincide for simple cases, but I don't see why importing some of that lack of clarity into the language itself would improve anything.
I could see the appeal of a cautious, conservative, least common denominator approach of limiting it to primitive types where match and == are the same, so nobody's intuitions can be violated (not even the wrong ones)... in a pre-1.0 world, maybe. Making a breaking change for it after promising not to break things any more does add some emphasis to the "over" in "overabundance of caution", though, in my humble opinion.
It's not, although the most obvious impact of opacity vs. transparency hadn't yet become apparent to me when I last wrote. Which is: (outside of the given scope), does the typechecker know that this (type/constant) is equal to what is written on its RHS? Transparent: yes, opaque: no. If a module m exports a transparent type T = bool;, then clients may say let foo: m::T = true;. If it's an opaque abstract type T = bool;, however, they cannot. Likewise, if the module exports a transparent const C: usize = 9;, then clients may do let arr: [i32; m::C] = [8; 9];. Whereas if it were an opaque abstract const, then they couldn't. So it's easy to see that our existing consts are quite definitely transparent. This is also what I was talking about with respect to associated consts (and likewise types) in generic code (and also just plain type parameters of generic functions): if the RHS is not available, then it can only be treated as opaque, exactly the same as an abstract type (resp. const).
The behavior of constants in pattern matches is just an extension of this: if the typechecker knows its RHS, then it can use it to check for exhaustiveness. Otherwise (if it's opaque), then it can't assume anything.
(I'm not necessarily advocating for adding abstract const to the language, but it doesn't have to exist in rustc in order for it to exist in our heads, and be useful there.)