Multiple Authorization headers aren't actually permitted by the RFCs. What you're sending is equivalent to
  Authorization: Basic dXNlcjp1c2Vy, Basic YWRtaW46YWRtaW4
Base-64 ignores whitespace and other invalid characters so that gets treated like
  Authorization: Basic dXNlcjp1c2VyBasicYWRtaW46YWRtaW4
which decodes to ("user:" followed by) the crazy stuff you're seeing.
  echo urlencode(base64_decode('dXNlcjp1c2VyBasicYWRtaW46YWRtaW4'));
  // user%3Auser%05%AB%22q%85%91%B5%A5%B8%E9%85%91%B5%A5%B8

IMO since this situation is prohibited, PHP's behavior is acceptable. Apache ignoring the additional headers is reasonable because multiple Authorizations don't make sense, and PHP combining them is not unreasonable because multiple headers means necessarily that they are equivalent to one which has the values combined and comma-separated.

My point was not to blame anyone that the RFC is not fulfiled, but to mention that different behaviour between httpd and php isn't what any user would expect, and therefore can potentially lead to security issues if an attacker deliberately sends two authentication headers. If authentication is handled externally through Apache and PHP_AUTH_PW is populated, I'd always expect that variable to hold exactly the password that Apache recognized & accepted. In the worst case, this could mean that I use the value as if it didn't need the special care user input usually requires and then

$ curl "http://path/to/page" -H "Authorization: Basic dXNlcjp1c2Vy" -H "Authorization: Basic GEuLi4gJzsgRFJPUCBUQUJMRSB1c2VyczsgLS0A="
user..pa... '; DROP TABLE users; --

would do lot's of damage.

If you want to do anything about this, a potential solution would be to check if Authorization headers exactly match "Basic <valid base64 without any other characters in between>" and only populate the PHP_AUTH_* variables if so.