I agree, that is already great, and i call it promising when thinking of tools that we can build above it.
That's the spirit. :)
This is a completely different and pragmatic approach: do not resolve source code conflicts, let them co-exist peacefully...
Indeed, I would argue that they aren't really conflicts. Two methods might use the same class name to refer to two different classes, but as long as the methods themselves retain information about the identities of those classes, we can reason about those references all we like.
Something close to typical OS job: loading different binary executable into separated space processes, maybe with .dll/.so dynamic loading/sharing. But then we have displaced the problem at interprocess communication level... How does spoon compare to this model?
It's very different. All the named entities are in the same space, what makes things work is that they have separate identities which are available to us.
thanks,
-C