problem using SetIdPrefix to resolve name collisions in views

Dennis,
Thank you for your reply. I have several concerns about your response. To clear up up misunderstandings, I'll deal with your 2nd paragraph first:

1. You wrote "your View identifiers must be without a namespace." Why? I see nothing that gives any hint of that anywhere in your documentation or in the behavior of my program. As I understand it, the whole point of using SetIdPrefix is that it allows me to use an abitrary string from the first half of the view identifier in my XAFML files and tell your code what the prefix is by what I pass to SetIdPrefix(). Do I misunderstand what SetIdPrefix does?
2. In your next sentence you suggest using "Finish_DetailView", that is what causes the name conflict, I have several classes named "Finish" in different namespaces. I chose to add the namespace on the front of the prefix because it makes it unique and the team can remember a clear convention for these prefixes. In that same sentence, you also wrote "unless you configured the "AuthorizeInvalidPurchaseOrder.Finish" prefix for your Finish type". That is exactly what I did as you can see from the first two lines of code and the line of XML that are in my original post.
3. Your last sentence indicates a concern about long identifiers and I see no reason for that. As I mentioned in my comment, the unusable nodes have all been accounted for and attributed to other issues. Those are all resolved and I no longer have any unusable nodes. None of them were attributed to "long identifiers". In the earlier versions (I believe it was something like 13.1.2 through 13.1.5) your software generated class names with fully qualified namespaces that are much longer than what I am using. As far as I know, there were no issues with those long names. What is your concern?
   As to your third paragraph, using short identifiers is not an option, I have name conflicts, that is the entire point of this support question and the original one, S19870. Setting prefixes is necessary (unless I rename classes which I am not inclined to do).
   I believe all the above isonly going to clear up some confusion but not resolve my core issue. Your first paragraph is the only part of your answer that addresses the core issue I have at this time. To summarize my current status:
   * I have a number of classes with the same name in different namespaces.
   * I have added calls to SetIdPrefix() in my application startup and that resolves the runtime issue.
   * However, the model generation code that runs when I use the Update Model command and when I open the model editor is unaware of the SetIdPrefix() calls I make in application startup. As a result, Update Model fails with an error message and opening the model editor fails with an internal error and a warning not to edit.
   * Given the failure of Update Model and the model editor, there is no option about "needing this functionality for design time," it is required for me to continue working. As far as I can imagine, this will be true of anyone who uses SetIdPrefix -- it must be "seen" your model generation code both at design time and at runtime.
   * Through experimentation, I have learned that adding calls to SetPrefixId() in the constructor of my subclass of ModuleBase resolves the design time issue. I have found that I must do that in every module that can see the views with the name collision. In my case I needed them in the the platform-independent module project's Module.cs because the classes are defined in the proejct. I also needed them in my platform-specific module project's WinModule.cs (mine is a WinForms-only application).
   So, basically you confirmed my experiment when you wrote that I can "set the prefix from within the static or instance constructor of your platform-agnostic module."
   To clarify that instruction, I think that "instance constructor of your platform-agnostic module" means the constructor of my subclass of ModuleBase. Is that correct?
   I am not sure what you meant when you referred to a static constructor, what static are you referring to?

Steve,
A1-3: My comments are related to the situation when there are no name conflicts and the SetPrefixId method is not used. So, you can ignore this comment if you have name conflicts, and thus are required to use the SetPrefixId method. This should work fine, as designed.
As far as I understand, you have no issues with design and runtime scenarios.
You are correct about the subclass of ModuleBase.
When I was talking about static constructors, I meant the following: http://msdn.microsoft.com/en-us/library/k9x6w0hc.aspx
Let me know if you still have unresolved issues, or require assistance with anything else. I will be glad to help.

Thank you Dennis. I have marked this as a solution but anyone reading it in the future really needs to read all the comments and the original article https://www.devexpress.com/Support/Center/Question/Details/S19870
I will add another "question" which will be a recommendation that you need to document SetIdPrefix

Thanks for your update, Steve. I think that once your suggestion (Documentation - Describe usage of the ModelNodesGeneratorSettings.SetIdPrefix method) is implemented, there will be no questions on this small feature.