I like your solution better than using NEWOBJECT() and specifying the program file in the caling code. That has a big impact when you reorganise your class libraries and move programs from file to file. At some point all your source code needs a search-and-replace to adjust the progrm file specified in the NEWOBJECT() calls - yeuch!

But I don't have a solution.
I think you're right, it's one of those issues where there is no right answer.
But we haven't solved the multi-developer contention issues either.
Even with only 4 related classes in a library (abstract, concrete and 2 specialisations) it's possible for there to be developer conflict.

Steven Black had a tool (hmm, about a year ago?) that would extract a class and everything it depended on into one file so that it could be worked on. Then would allow you to reverse that and put the changes back.

Are you using source safe? Could you use multiple check=out and merging to handle it?
Personally I don't like that, as it puts a lot of responsibility on the person doing the merge to handle potential conflicts in the two code sources. It also means that you need a third module level test after the developers have done their individual (perhaps overlapping) changes and testing.