First of all, I don't think Composer is trying too hard to be a PHP version of NPM - there may be similarities, but differences are to be expected. It may not be the best way to understand it to think of the tool as NPM, Maven, Rake or whatever, but translated into PHP.
Secondly, understand that Composer solves 'problem' of autoloading in PHP. Having two different versions of a given library in your
vendor/ directory is not a state of affairs that Composer strives for here, and perhaps that is a good thing. Everything in your
vendor/ directory is accessible in your user-land code via the same autoloader. Why would you want more that one class with the same fully-qualified classname? What should happen if you refer to that classname in your own code - which one do you want? I'm not sure we should even want PHP to know what to do when confronted with two different pieces of code each trying to interact with subtly different versions of the same dependency.
Composer replaces told like Pear and Pecl in PHP, and was partly inspired by the PSR-0/4 standards for PHP autoloading. It gives you all your dependencies in one place. It makes dependencies part of your project, not part of its documentation. It uses the semantic versioning that is becoming standard in PHP libraries to find versions of your dependencies that play nicely together, and if there aren't any, it tells you as much.
We've never had a tool like this in PHP before, and the change it has helped precipitate is much greater awareness on the parts of library and framework authors on how their tools work or don't work together. Much is being duke in the community to address these challenges. Composer may not be exactly like NPM, but its handling of PHP package management is ideally suited to the language, and really fills a gap which made deploying a large PHP application a pain in the neck before.