I've not had a problem but I really didn't see this coming
Which is what happened when I tried to use them; it's like crossing train tracks when the train is supersonic... you never hear it coming.
For PHP to come so far in being sensible this seems like a last minute hack which hasn't been thought about.
I never found namespaces to be sensible when introduced when we already had the new object model; (if you can call PHP 5.3 'new') the only reason I can see to use them is to restrict scope, but since you can access them globally that kind-of defeats the point of restricting scope... well, other than yet another lame attempt at addressing namespace collisions, and really the ONLY way to do that is pay attention as a coder and to not blindly cut/paste code together from different sources.
PSR is just an attempt to standardize practices... I agree with some of it and disagree with other parts; much of it is just common sense from a security standpoint. Honestly since PHP-FIG has little if anything to do with the ACTUAL PHP coding standards, it's a cute suggestion, but not something I'd take as the gospel. Their idea of making frameworks interoperable is 'cute' -- assuming you believe in using frameworks in the first place...
Composer seems better than what I've heard about PEAR but then again I seemed to manage this long without ever touching PEAR.
They're both pointless garbage and more unstable in implementation than PHP itself (and given the changes to PHP the past decade, that's saying something). I won't use either for the simple reason you cannot guarantee a hosting provider will even allow you access to either -- meaning unless you are micro-managing your own hosting or restricting your product to people who can do so, PEAR and COMPOSER are completely and utterly useless on a 'generic' application where you don't know where it will be hosted. You might as well use ASP or JSP instead of at that point.
The truth of the matter is that I've had my head buried in the sand since version 4 (4.4.9? I think), I had no clue version 5 had so many changes so all this is kinda new to me and I'm working on something open source that can stand the test of time (well maybe until version 6 at least).
There are a lot of good changes, and a LOT of garbage. Object scope and PDO being the highlights. The full object model of PHP 5+, in particular the scope controls of 'restricted' and 'private' fix a LOT of the possible security issues; something I think namespaces was trying to do, and failed miserably at.
I'm one for creating simple but elegant coding solutions. Some frameworks built today seem at the very core overly complex wrapped up in pretension. I think if we all coded smarter in both senses of the word we wouldn't need to keep laying down these MUST do this MUST do that rules.
Well, rules are good in that they make it simpler -- just follow the rules and you are good - but you have to question certain rules that contradict reason.
I mean, I have my own set of rules:
1) only one <?php ?> pairing per file...
2) that <?php should be the first thing in the file, ?> should be the last.
3) always use ?> since omitting it like some people say to do means any code appendage will be executed, not shown; running code client side HAS to be more secure than server-side, and it's not like you can't just put <?php or ?> in a code appendage.
4) security info like mysql un/pw/host should NEVER be stored in the global scope.
5) the connection to the database should NEVER be stored in the global scope. (so no mysql_ functions)
6) the connection to the database and ability to run queries should NEVER be passed to code that outputs markup
I could go on for a bit. Some of those might look like what the various PSR levels say -- but mine were established for internal security, NOT interopability... in my mind interoperability isn't necessarily a great objective given it just opens security holes...
But then I'm the nut who thinks that include/require should only be able to open files with a .php extension, we should only have been allowed to use _once versions in the first place, readfile should NOT be allowed to open files with a .php extension, and that the PHP 'shorttags' of <?php <?= and ?> should be removed from PHP entirely to make it work like a REAL programming language and not blindly output stuff when called directly. I'd possibly even say we need a NEW file extension, .phpi that is the ONLY file type allowed to be called by include/require, and that the server could block user side direct access to.
Why? because it would plug major security holes.
But as you said, much of PHP-FIG's "must" I'm not wild about being "must" -- I much prefer "NEVER" to "MUST". It's usually better to say what you shouldn't be doing as opposed to what you MUST do... and even my above rules I don't treat as the gospel and will break them when/if it makes sense or there's no risk. I'm different in that though, seems like most people seem to get their panties in a wad if you tell them "don't do that!"
I'm sick of following the fashion on coding standards as we switch between which standard organisation has hit the front of Forbes Magazine.
Heh, as I say, taking technical advice from the pages of Forbes is like taking financial advice from the pages of Popular Electronics.
Most everything that you find being popularized that way is more sick buzzword than a matter of fact, and that's why when it comes to PHP I restrict myself to what's on PHP.NET and on a STOCK PHP install. Anything else I take with a mountain of salt.