I have a blue print of publications as below. A_Preview | B_Live
B_Live contains some localized components and also components created locally.
We would like to introduce publication A1_Prelive in between as below. A_Preview | A1_Prelive | B_Live
I have verified this in our development environment and found no issues and everything seems to be working perfectly. However I would like to know are there any problems with this blueprint change in the long run or in terms of best practices.
There is no such rule for that, but Yes! always the best practice is Design your blueprinting architecture first and then start the development to avoid any rework and unnecessary effort. You can change the blueprinting structure in the middle of development because of some major changes in the project, but in that case you have to be more careful regarding the dependency. For that scenario I will suggest to perform this task in lower environment first and create a proper checklist list before you move to Production environment. You have done it smoothly in you environment because you are introducing a new publication. But if you have to move this publication to higher or lower level in future, then you might get some issues.
The only issue you'll encounter when changing Publication relationships are possibly naming conflicts (i.e. if an item has the same WebDAV url as another). This isn't a problem with new Publications "in-between" an existing pair of parent-child Publications.
As for why you're creating this setup, Publications for what we typically use Target Types (Purposes) is not typical for BluePrinting. I have seen this somewhat fit one use case (see this post) for a long term review scenario at one customer (which they did not implement).
The biggest challenge would be "merging" changes across the Live Publication, PreLive Publication, and Preview Publication. In typical setups, you have a single source for content where this isn't a problem. With this BluePrinting hack you want to be sure the inheritance is correct or you have a way to move localized changes to their sources in the BluePrint.
With Live as the lowest child, unlocalizing would be a way to accept changes for the site. Again, I don't know what this is like in practice, but I would not recommend it as a best practice or first choice without more context on what you're trying to do.
