You've renamed the class, but the header is still named "NSSomeClass.h", so the C-side submodule is named that too. (You can test that it's the name of the header and not the class by, well, renaming the header.)
I don't think we're likely to change this, even though it is kind of funny. You can manually control the names of submodules by writing your own module map for your framework, but that'll affect Objective-C as well.
(It's not really intended to use API notes on someone else's framework, because they might be incompatible with how another library is trying to use that framework. This could manifest itself as errors or as compiler crashes. But if everything compiles you won't see any weird problems at run time.)
That makes perfect sense. Thanks for explaining it, Jordan.
I did note that I can make set the SwiftName of classes, tags, et al to MyFramework.SomeClass and it works fine (although it then requires the prefix). I should stop pretending this framework is in Swift and just get on with it
Thanks to whomever implemented the API notes code - it's really nicely documented and structured enough that I was able to easily infer the various options and their purpose