Hey Igor,
Thanks for taking a look.
I understand your concern, they are both technically incorrect - but wouldn't it make sense for compilation and testing to follow the same classpath? Otherwise there is an inconsistency, and that inconsistency exists solely in eclipse with m2e configured projects.
It sounds like you are suggesting that debugging tests with unexpected classes on the classpath is somehow more surprising than with classes missing. I would argue that this is actually the opposite, because every indication from the "Maven Dependencies" classpath container suggests that the class does in fact exist. The project looks like it is correctly referenced from the user's point of view when viewing the project "Build Path", and "CTRL-3" links to that class take you to the referenced project, and so on. At least with this "one big classpath," people generally understand that Eclipse has a limitation, and accept it. They understand that there will be test classes on the classpath that are not available from a real maven build. Why reverse that concept just for this one scenario?
Speaking of reversal, let's look at what happens when we reverse the scenario. Let's say we apply the same reasoning to the primary compile classpath: By this line of thinking, you would have compile errors in eclipse because classified dependencies are not available, but compilation would succeed in Maven. Does that make sense? I imagine not, otherwise m2e would enforce this and developing with maven and eclipse would be useless (without manual configuration.) That's the same scenario that exists today in tests.
If there is no data to support either side, then why not at least favor the principle of least surprise, and make these two things behave the same way?
~Lincoln