Not really, I think of it as one single code base, with the main script having a IS_APP global variable which determines if the chunk of the code handling stripping is executed or not, and if the plugin code chunk is executed or not. We are still talking about Blender Python scripting, it’s as simple and short as it gets with regards to making apps with so many features.
Conversely, however, doing so means that one misses out on beneficial improvements provided by updates to Blender, unless one takes on the question of keeping up with any changes to the Blender API incurred in such updates.
At this point I’lll just say I think you are overthinking every point here.
Everything is a balance, I’m suggesting an option which provides advantages of both worlds: on one hand you don’t need to maintain a completely custom editor, on the other hand you don’t need to keep maintaining it as fast as Blender.
What you said would only be a disadvantage if the approach I mentioned disallowed you from maintaining it as fast as Blender by some inherent design, but that’s not the case. If you can update it as fast as Blender, then great, take advantage of any new features as soon as they are available, if not then it’s still usable to anyone who has decided to update their Blender for the usual use cases.
Is this still true with the newer versions of Blender? What I’ve been hearing is that those made some significant changes to the UI, making it more user-friendly
It’s better than than the 2.5 era, but it’s still not for some people. In fact most programs don’t please most users, so you shouldn’t tie your tool to users of only one program, which seems to be Panda’s approach already about everything else. Blender being usable as a scene editor seems to be not due to choice but due to limited development resources.