They are all lowercase nowadays.
They were always case-sensitive to use. I used upper case to make it stand out in my message.
|have try dig up the troff sources to an early draft of the original and do
|a "grep -i should * | wc -l" through it. I bet the number is very small
|and "can" is zero.
They offer lots of hints like "can be implemented efficiently" or
"conforming implementations cannot count on", which turns "can"
into a "dying butterfly". (In the rationale's.)
It always say. "conforming implementations shall not count on."
The standard has to be as precise as it can be. If there are implementation grey areas, then the standard needs to state that too.
Again - we were careful when we wrote original documents (and had lots of arguments as you can imagine).
As for what you read, I'm not worried. The fact the over time, standards stop being what they were originally intended and take a life of their own. POSIX is less of an issue than say, C++ or even FORTRAN for that matter. But over time, a new group of people want to "make their mark." Some of us grew tired of arguing. We got what we originally set out to do, and I left the POSIX work soon after the *.2 began. I worked through one draft of it, but was not there for approval, although I helped with *.4 at one point.
Someone implementing something new, be it a language or a system, should be familiar with the standards. They is a lot be learned both good and bad. Reinventing things, particularly bad ideas, is hardly for the greater good (although the implementor might find it fun). e.g. C++, IMO, is a great example of what >>not<< to do. The core POSIX.1 interface, think is excellent and gets to the point. After that, YMMV and the value you get from it also is a bit variable. But thinking the world should be stagnant and believing that C or UNIX (or modern Unix, a.k.a. Linux) is "the end" is hardly a good idea either.
So, reading and learning about them does have some merit. The question is how much and how far to go.
Clem