So what formats does Panda import properly, besides egg in 2022?

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.

I’m honestly not sure that it would work out that way in practice, or that if it did, that it would be as easy to maintain as you expect.

Either way, you have two code-paths–whether they’re stored in one code-base or two–which interact with Blender in different ways, and both of which call for maintenance.

An export plugin would be one of those, and thus an app would incur the maintenance of both the plugin and the app-stuff.

I don’t think so.

And I’ve acknowledged some of those advantages. I just think that you’re underestimating some of the disadvantages or costs.

As to balance, sometimes the median path is less effective than a path that hews to one side or another, I would say. Or, to put it another way, sometimes balance is achieved by having more on one side than another.

If we’re talking about maintaining it “as fast as Blender”, then we’re back to the issue of the Blender API changing and potentially breaking the tool. If we’re not, then we potentially miss out on useful updates.

Now, in all fairness, there’s a question of how likely those useful updates are–perhaps it would be fine to have a static program.

This is the impression that I had.

Of course–as you say, no program is congenial to all users.

Still, I’m dubious that the old wisdom of Blender being difficult to work with is still as true as once it was, and thus I’m not convinced that it’s as big a hurdle now as you suggest.

This is likely true, in all fairness.

That said, it occurs to me that many games are likely to want for some sort of scene-editor, and whatever the reason, Blender does I think tend to be the recommended tool for that purpose…

Perhaps that will change as some of the community-made scene-editor projects mature, of course–we’ll see!

I still think you’re overthinking every point.
I’ve maintained exporters for some niche 3d and animation files from Blender back in the early 2010 and they weren’t anywhere difficult to maintain and they were <500 lines of code, I don’t see how apps would be significantly more difficult,
At one point you have to stop guessing and just try it, otherwise you won’t get anywhere.

And I still think that you’re underestimating.

That’s fair–but I’ve seen maintenance be a problem for Blender-to-Panda exporters, as I recall. And I would imagine that an app would likely incur more maintenance than an exporter (especially as the app would presumably contain the exporter). Plus, as noted, there are two code-paths to maintain, rather than just one.

Sure–but that applies to both our sides of the argument, I would say: One can try it out and see whether it’s easier than one expects, and one can try it out and see whether it’s harder than one expects.

In any case, unless one of us is inclined to actually make these things, we are just arguing about them. shrugs

So, shall we then agree to disagree? I think that we’ve both made our points, for the most part at least.

I’m done with this discussion. Arguing for the sake of arguing goes nowhere and it is definitely what you are doing here, whether you realize or not. This has been a very unpleasant exchange.