As of Spring 4.0, the set of mocks in the org.springframework.mock.web package is now compatible with Servlet 3.0.
Reading this I don't understand it became incompatible to servlet-2.5. As a matter of fact MockHttpServletRequest became incompatible to servlet-2.5. This is fine, but IMO should be worth mention it somewhere in the reference documentation (e.g. at "3.9 Testing Improvements").
When I posted the issue I didn't read [3.4 Java EE 6 and 7|docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/htmlsingle/#_java_ee_6_and_7]:
Java EE version 6 or above is now considered the baseline for Spring Framework 4, with the JPA 2.0 and Servlet 3.0 specifications being of particular relevance.[..] it is possible to deploy a Spring application into a Servlet 2.5 environment; however, Servlet 3.0+ is recommended when at all possible.
Maybe that part of the documentation covers the issue enough.
I think it's still not very clear - it seems to me that Spring 4.0.0 is pretty much only compatible with Servlet v3.0 onwards. An issue such as not being able to mock the servlet context could be a problem for many projects - because even if you can run your app with Servlet v2.5 and Spring 4.0.0 you can only test against earlier versions of Spring or newer versions of the Servlet spec (therefore the tests are not a true reflection of the app).
IMHO 'is recommended when at all possible' isn't very explicit.
I've refined the wording in the What's New section to:
"In order to remain compatible with Google App Engine and older application servers, it is possible to deploy a Spring 4 application into a Servlet 2.5 environment. However, Servlet 3.0+ is strongly recommended and a prerequisite in Spring's test and mock packages for test setups in development environments."
I'll also add a corresponding note to the testing chapter.
The underlying rationale is simply that Servlet 3.0+ brings significant simplication to our codebase, in particular to the MVC test framework and the Servlet mock classes. At the same time, it is almost trivial to preserve Servlet 2.5 runtime compatibility for the time being, through making sure that our Servlet 3.0 based code paths only kick in when their functionality is actually required (which is a good framework design rule anyway).
The price to pay for application development setups is to have the Servlet 3.0 API on the classpath if you're using Spring's test or mock packages. This shouldn't be a big deal in practice: You won't be able to test Servlet 2.5 compliance in your unit tests that way but well, you'll find out about that in integration testing later on. If you can live with that compromise, developing for a Servlet 2.5 deployment environment is still entirely valid.
Note that the primary goal here is to support existing Spring apps in their upgrade to Spring Framework 4, as well as reusable apps that have Servlet 3.0 based features themselves but want to adapt to Servlet 2.5 when facing it in production. We do not recommend starting a new application for deployment on Servlet 2.5 only (except for Google App Engine possibly); that said, we're there to help you with Spring Framework 4 based application setup even then.