Vincent, see below for some comments I have related to your specific POM.
The fix involved adding a raw-project cache to the project builder.
MNG-2054 was the flip-side of this problem, in that it had a problem that came from using the processed-project cache for assembling the project lineage that would eventually be used for inheritance...in that case, projects which had already had inheritance operations performed on them were causing multiple inheritance of the same configuration from ancestor POMs.
In this case, turning off that caching means that POMs which have broken <relativePath/> links to the parent POM, and whose parent POMs are not in the repository, will not be able to find their parent in a multimodule build - even though the parent has been cached as part of the current build process. To fix this, I've implemented raw-project caching, which are the project instances without interpolation, inheritance, etc. operations performed on them. This allows assembleLineage(..) to lookup and use these POMs, and have subsequent inheritance operations succeed without injecting the same config multiple times.
Vincent, although this use case has been fixed in SVN, I'd strongly suggest you add a relativePath element to the testdata POM's parent section, so it can be built in isolation, even if the parent POM isn't in the repository.