Thanks for the post, this is something I don’t think I have seen before unless I have a reference to some of the file. Definitely a head scratcher for me. Inviting other developers here to to provide there opinion of possible causes for this.
One thought I have is that Xcode keeps a lot of build artifacts and project-related data in its derived data folder. This can often lead to stale or incorrect information being used by Interface Builder. Have you try to go to Product > Clean Build Folder (or Cmd+Shift+K). Do this for both projects/targets if they are in the same workspace.
Even if your NIB files are separate, the custom classes (e.g., your AppDelegate subclasses, custom NSWindowControllers, or NSView subclasses) that are referenced in those NIBs might be accidentally included in the wrong target. If a class from App A is somehow included in App B's target (or vice-versa), Interface Builder for App B's NIB might try to instantiate or show properties from App A's version of that class?
The Info.plist for each target specifies the main NIB file to load (NSMainNibFile). While this primarily affects runtime, an incorrect entry could potentially contribute to confusion if Xcode's internal indexing for IB is somehow using this as context. Select your project in the Project Navigator. Select each target in the targets list. Go to the Info tab. Look for Main nib file base name (or NSMainNibFile if viewing as source). Ensure it correctly points to its own MainMenu NIB.
Given your description, I'd put my money on a reference to the other project file as the most probable causes. Start with a clean/clear derived data, and then meticulously check target memberships. Maybe the project file should be checked and reviewed here.
Albert Pascual
Worldwide Developer Relations.