[=~] should not be causing the warning, however [=abc=] and [.abc.] will.

You are right.
It actually was part of a compound expression, and I'd overlooked that the other parts were also relevant. The following line generates the error message:
  $x=preg_match("%[=~]|<[>=]%", "test");
(PHP 5.3.8, PCRE 8.13.2011-08-16).

Regardless, the documentation does not mention the '[=..=]' POSIX collating-element construct. It does not mention the '=' symbol at all. This should be fixed in the documentation. Ideally, the documentation should also contain the phrase 'POSIX collating element', so that it appears as a search result when people search for the text of the error message.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Documented at http://php.net/reference.pcre.pattern.posix

The amended documentation is slightly inaccurate.
The documentation states
"Supplying an expression with a character class that both starts and ends with <literal>:</literal>, <literal>.</literal> or <literal>:</literal> characters to PCRE is interpreted as an attempt to use one of these unsupported features and causes a compilation error."
Unfortunately, the compilation error is also triggered when "supplying an expression with a character class that start with a <literal>:</literal>, <literal>.</literal> or <literal>:</literal> character, followed by a different character class that ends with that same literal".

Also, I strongly urge you to formulate the text in such a way that it includes the phrase "POSIX collating elements", so that the page will be a top search result when searching for the error message "Compilation failed: POSIX collating elements are not supported".

I've reworded the disallowed element list to match the error message as suggested.

Note however that the "followed by a different character class that ends with that same literal" is not actually correct, also note that I cannot reproduce the error with the second example %[=~]|<[>=]% (http://3v4l.org/sdJ5M) - it's possible this was a bug in an earlier version of PCRE.

The true rules relate to the fact that \ is not an escape character in POSIX bracket expressions, and in reality there *should* be no conflicts (the only way to cause a conflict would be with an empty character class []), and this is somewhat beyond the scope of the PCRE documentation.

More information on the POSIX sequences that are the root cause of this problem can be found at http://www.regular-expressions.info/posixbrackets.html.

You're right, I get the error message with my original use-case on a machine with PHP 5.3.8 using PCRE 8.13.2011-08-16, but not on a different machine with PHP 5.3.17 using PCRE 8.31 2012-07-06. Upon checking the PCRE changelog at http://www.pcre.org/changelog.txt, I find this bug was noted and fixed in PCRE version 8.20.

Thanks for making the changes!