You are right that the problem has to do with the @RunWith being on a super-class. But I found that the problem is more specific than that. When the super class is binary and there is no source location attached, then the problem happens for me. I am not exactly sure what info is missing, but it does appear that not all debug info is included.
Are you saying that you see the problem whether or not the spock.lang.Specification class is binary?
Let me be more specific (this part is as much for me as it is for you, so I know what I did when I look at this 5 months from now):
org.eclipse.jdt.internal.junit.launcher.JUnit4TestFinder$AnnotationSearchRequestor.acceptSearchMatch() is a method that tentatively accepts a class or method that contains a test annotation. The match is only accepted if the offset of the Java element's name range is valid. However, the name range of the Specification type's name (ie- its source location) is invalid.
However, if the core spock jar has its source attachment included or I import spock source directly into the project, I am able to run the test cases by selecting the compilation unit.
FWIW, I tried to create the same situation in a purely Java project (ie- binary super class with @RunWith annotation no source info, and source test class that is a subclass). I cannot directly run the subclass by selecting the compilation unit, but only the actual class. I'm inclined to believe that this is another JDT bug, but if the solution is to have a source attachment or create proper source info in your jars, then I'd say it is minor.
Is this something you can try to see if you experience the same behavior?