On your first point, as long as everything is still in a project namespace, I don't see why a clash would occur.

On your second point, I almost never use an IDE, so I can't speak to that.  It may be a good reason to keep things as they are.

Why I don't like nested namespaces:

* You end up with multiple classes (and files) called the same thing.  This can be a problem for some build systems and makes it a PITA if you want to move things around a directory structure.  (In the LAS reader, we really have 3 "Reader"s and it's hard to tell which is which when you're going through the code without an IDE that does code-folding.)
* I've been burned quite a few times by problems with not finding the right function because of argument-dependent lookup.  They can be confusing problems to track down.
* You have to be more aware of context with namespaces and that can be easily avoided with a little more creative class naming.  I think nested namespaces have often been used as an alternative to a new name, but they come with baggage of occasional lookup ambiguities easily avoided with new names.
* On a more personal note, I like code that is succinct -- where I can read a lot of it in a small space.  If you aren't putting "using namespace <>" in header files (and you shouldn't), you often get variable declarations that are absurdly long.  The "auto" keyword of C++ 11 was a godsend when it comes to making code readable again, relegating something like "for (foo::bar::baz<SomeOtherReallyLongName>::const_iterator iter; ...)" to the dustbin.  Lots of namespace nesting also seems to encourage people to typedef lots of things with names that could have been used as such in the first place.  I just don't see any reason to encourage verbose naming and nested namespaces do that.

To me, namespaces are best used as a mechanism to prevent name clashes between systems not controlled by a single entity, not to use within a system.  But I don't use IDEs very often and I'm just throwing out my opinion, here.