Is this for real? An new option has a default value that cripples XSLTProcessor 
WITH ITS DEFAULT VALUE and it’s UNDOCUMENTED?

From NEWS:

- XSL:
  . Added xsl.security_prefs ini option to define forbidden operations within
    XSLT stylesheets, default is not to enable write operations. This option 
    won't be in 5.4, since there's a new method. Fixes Bug #54446. (Chregu,
    Nicolas Gregoire)

Documented in the PHP documentation. You know, the web site where you go when 
something does not work…

@os3476 if the code/package author is unable to make a change for whatever 
reason, feel free to be constructive and help the PHP community by submiting a 
doc edit at https://edit.php.net/  Anonymous users can submit patches.

What about this?

@@ -42,2 +42,2 @@
- When you introduce a new configuration option, set its in-code default value 
(when no value is given in any ini file) to the desired default value;
+ When you introduce a new configuration option whose desired default value 
breaks existing code, set its in-code default value (when no value is given in 
any ini file) to having no effect at all compared to the previous version, and 
add it with the desired default value to the php.ini.dist (or whatever you call 
it) file, so that people who upgrade see the new option and can anticipate the 
problems;
+ 
@@ -44,2 +44,2 @@
- When someone submits a patch that looks urgent because of security issues, 
accept it as quickly as possible.
+ When someone submits a patch, no matter how urgent it may seem to apply it, 
check if the corresponding documentation was written before accepting it; /* I 
take it you don’t release code unless it includes the corresponding unit tests. 
Documentation is the same. */
+ 
@@ -46,0 +46,2 @@
+ To that effect, make sure everyone who submits a patch know how they can be 
anonymously constructive about documentation as well;
+ 
@@ -46,2 +48,2 @@
- Provide online documentation for the latest version of PHP;
+ Provide a documentation archive, so that people can consult documentation that 
matches the PHP version they use and not just the latest that they likely can’t 
use because of their hosting provider, LTS Linux distribution, company policy or 
whatever reason;
+ 

There. That’s a constructive patch to your methodology that I’m submitting. Let 
me know when it makes it to the master branch.

- Patch to what? 

- Doesn't seem constructive or concise

- Anyway, that appears to be non-xsl related and so you should log another bug 
for it.

- Antagonizing open source developers with comments like "I take it you 
don't..." is often going to be counter productive

- Antagonizing someone who is not even a user of XSL, and definitely is not 
involved in its development, and who did log a bug to try and improve things 
(i.e. me) isn't going to help anything at all

@sixd

- A patch to the way changes are obviously accepted in the PHP code base even if the corresponding documentation was not written.

- ...

- The package was changed to “Documentation problem”, so I don’t see the need to resubmit a report that will obviously result in a request for me to provide a patch again.

- There was nothing antagonizing in my “I take it you don’t release code unless it includes the corresponding unit tests.”. It was actually an acknowledgement that I believe that patch submission is done properly with respect to tests. (really).

- You forfeited your rights to not being antagonised by serving me the boilerplate “if you don’t like it, be constructive and submit a patch, it’s ok for people to be incompetent if they publish their source code” answer so dear to open source developers who have problems admitting it when they screw up, even though you’re not even a user of XSL, and definitely not involved in its development, and did log a bug to try and improve things.