I'd need to... rearchitect some stuff, and I don't know how soon I'll have time to actually implement it, but... maybe I can do something like that, yes.
Especially given the imminent 5.7 release, which means I'm going to have to try and carve out time to dig into that anyway...
Some of the things you listed will probably still be gone tho, since they're basically stored with the mesh data (definitely the lightmap, maybe some material settings)
Thanks for considering it!
I don't know how your code works internally, but maybe read the existing mesh asset data and copy over certain properties? Though I can't think of a way to make that not confusing for the user if there are things they still want to be changed in Hammer. You could leave it as an option that's off by default.
And I understand that the actor and mesh asset names change if you remove objects in Hammer, so I get it if my request is unfeasible.
Quick update on this, since it's been a while:
I have a plan, but I didn't manage to get it done before the 5.7.0 update because of my ongoing health situation. I'm pushing the 'vanilla' 5.7.0 update without these changes first, but hopefully I'll manage to get something done for you by end of year.
A thousand apologies for how disgustingly long it's taken, but the 5.7 and 5.8 Fuck Global Warming builds now have a new feature that you can turn on in the settings that compares an opened file to the previous import (if that data is available), and should sort of give you what you wanted, in that it should only touch brushes and entities that have changed.
Unfortunately, I spent so long working on this in bits and pieces that I... completely forgot your original ask was mesh only, which would need... Another Layer on top of this.
I'll see about getting you a 2.7a version that should hopefully not take quite this long to appear, altho it's... quite a tricky proposition, given how everything fits together, so I hope this at least gets you somewhere.
To unpack that "tricky proposition" thought:
The only heavily used format HammUEr supports that actually has built-in fixed ids from the editor side, is Hammer's VMF, really.
Some of the editors out there add their own version of this maybe when writing out Quake/Valve220 MAP files, but there's nothing there you can trust will be the same between runs In The Format Specification Itself, which leads to ids basically being self-assigned based on order they're encountered in the file, which makes it harder to keep anything already loaded without doing a whole lot of extra guesswork.
tl;dr: it's (relatively) easy to find things that haven't changed, but things that have changed can be ???
