Thanks for the attached project. I've reworked this and checked it into the spring-framework-issues project with this commit:
I would recommend checking that out and taking a look at it. You'll see that I've set up an xml_centric approach and a java_centric approach. When the container is bootstrapped via AnnotationConfigApplicationContext, it is simply not possible for MapperScannerConfigurer to do its job correctly. This is a fundamental limitation that we won't change. When the container is bootstrapped via GenericXmlApplicationContext, MapperScannerConfigurer works just fine.
The problem is that MapperScannerConfigurer needs to perform additional registration of beans via a classpath scanning process. Implementing BeanDefinitionRegistryPostProcessor works well enough when bootstrapping via XML, but as you've seen, not with @Configuration. As of Spring 3.1, the @Enable* and @ComponentScan annotations are the answer to introducing this kind of support in the @Configuration world. For example, @ComponentScan performs scanning and registration very similar to that which MapperScannerConfigurer does.
I would recommend reaching out to the MyBatis developers and seeing if they're interested in developing an @Enable*-style annotation that performs the same work as MapperScannerConfigurer.