Right, but your solution is for a problem that does not currently exist.

I can't see a situation arising where importing an unofficial part with all its dependencies could in fact cause this. By definition there can only be a single entity in the parts-library with a given TargetName. The only times that you would have two files with the same filename in your library are if one file is in 'parts' and the other in 'parts\s' (or similar), in which case they have unique TargetNames; or if one file was in 'parts' and the other in 'models' (or 'unofficial\parts' if you're into that), in which case the one in 'models' takes precedence when doing a lookup and the one in 'parts' is simply ignored (or vice-versa if your search-path is configured the other way around).

The closest I can see to your example would be if you imported two parts which both had a dependency on the same subpart (or primitive); in that case it would be redundant to import the subpart twice and it's the application's problem to ensure that this does not happen. In fact, your solution would not only allow duplicate imports, it would actually make them more likely to happen.

I've just checked, and MLCad actually has a nasty bug here: it actually loaded the above code! This absolutely should not have happened, since it merrily created two pages with the name 'a.dat' - something that it will not allow you to do if you try and create or rename a page. I'm mildly surprised that it didn't crash on loading, in fact. (There's a second bug, too: it seems to think that TargetNames are case-sensitive - 'A.dat' and 'a.dat' are regarded as being different, which is wrong.)