For the record, my framework does look like the frameworks you're describing, complete with a "Current" link pointing to "M", because that's the way frameworks are supposed to be arranged. That has been well documented for many, many years. I have been distributing my framework for 13 years in that form (but using different version letters) with many satisfied application customers and several well-known corporate licensees of my framework used in popular commercial products. We all agree that it is necessary to worry about what our software does -- that's why we test it. But despite Apple's sorry record with respect to documentation in recent years, I am a firm believer in up-to-date, complete and accurate developer documentation. It not only helps to avoid the time wasted and mistakes made by trial-and-error programming, but if done right it provides assurance that one is doing things the way the developer intended.
Also, I am certainly not the only person using multiple versions or versions labeled other than "A" in shared frameworks. That, too, has been part of my routine and used successfully by my customers for many years and well documented since the beginning. I just now examined the many frameworks installed in the standard shared location, /Library/Frameworks/, on one of my Macs. The Adobe Air framework uses a single version but labels it "1.0" instead of "A". The HPPml framework uses a single version but labels it "B" -- so there's another example of not using "A" but instead doing it the same way I do in my embedded framework. Ditto the HPServicesInterface framework. Apple's PluginManager framework contains two versions labeled "A" and "B" -- so that disproves your assumption that Apple always uses only one and always labels it "A".
Also, I do have my workspace set up correctly. It is completely self-contained, containing both the framework project and the application project. The framework is linked into the application, and I have confirmed that the workspace builds the release and not the debug version of the framework into the built application. Neverthelss, I believe you are mistaken in asserting that frameworks should never be built separately. I believe they should always be built separately first -- that is the way I have done it for 13 years. Once you've reached a certain point it is useful to add a test application or two to the workspace. But once a framework is completed, I know from long experience that it works perfectly well to build additional application products by putting the built framework into the standard shared framework location or a special location noted in your application's build settings and leaving it out of the workspace, and it also works to put the built framework into the application workspace or project with its headers but without its source code. Many developers never even get their hands on a third-party framework's source code and can't include that in their application workspace.
So, let me be perfectly clear about my question: Is there some way in Xcode 7 to specify a framework version other than "A" when codesigning an embedded framework from the target's General tab at build time? If so, what is it? If anybody knows of any documentation, please refer me to it. Thanks.