Here is what little I know, towards answering some of your questions:
1. Eigen2 support modes are tested in current Eigen-trunk, see the test/eigen2 directory which contains a copy of the eigen2 test suite running on eigen 3 with compatibility mode. To be more specific, looking at the CMakeLists there, what this tests is EIGEN2_SUPPORT_STAGE10_FULL_EIGEN2_API. The other porting stages are completely untested, according to grepping in test/.
2. At least KDE is still using Eigen2, or was as of a few weeks ago. I recently received an email from a KDE maintaining who was porting parts of KDE from Eigen 2 to Eigen 3.
Now, let's ask what are the costs of having Eigen 2.0 around? And how do we lower or avoid these costs? Removing Eigen 2 stuff is an option, but not necessarily the only one.
It seems from hg logs that the 2.0 branch only received some documentation fixes since the 2.0.17 release. So it seems to be low-maintainance. If needed, that documentation-system maintainance cost could be brought down to zero by stopping running doxygen on it, and instead keeping online a frozen archive of the current doxygen output.
What I don't know --- it is for current maintainers to tell --- is how much maintainance cost is incurred by Eigen3's compatibility modes. If it were significant, it could make sense to remove these modes from Eigen trunk and communicate in the documentation that these modes are only available up to version e.g. 3.2 and therefore people porting from Eigen 2 are invited to first port to Eigen 3.2 before moving on to newer Eigen versions.
If Eigen 2 documentation or other mentions on the website are confusing visitors, then that's a real problem that needs to be solved, but perhaps it could be solved by big red <blink> (oh wait, we just removed support from that html tag...) warnings, while keeping Eigen 2 available for people who still need it.
Thanks
Benoit