Our current approach to doing parent flows and importing beans doesn't allow third party creation of flows that inherit from our flows, which is primarily a thing in the case of the admin flow framework I built, though it also breaks if you tried to inherit from one of the SAML flows.
The bug is that SWF has really broken flow building logic, and one of the bugs is that it mis-handles resource import such that the path to the bean imports is always required to be relative, and is resolved based on the child flow, not the original parent (and doesn't support property replacement and about six other bugs). This is not what they document for the bean-import element, and I think that's a known bug that they just aren't going to fix.
I would love to override the FlowModelFlowBuilder class somehow because that class has about a half-dozen broken "features" but I can't see an easy way to do it. I'm starting to think we should consider forking SWF anyway, since it's basically defunct as it is, and we could fix a lot of this nonsense ourselves easily enough.
From what I can tell, the workaround people have used is to move all the bean importing down into the "concrete" child flows. That might conceivably work for some things but wouldn't allow anybody to inherit from one of our "real" flows since those are concrete and have to do the importing. I guess that may be the best we can do for now. A lot of our "real" flows are abstract anyway since the final step is define the message decoder step at the bottom level.