I do not recall if I've suggested this before or not, but here's'a we go anyways.
Instead of making a vehicle go boom (or poof if explosions are disabled) we just total them out instead. Maybe we could still spawn an explosion where they are if it is enabled, but it seems like wasted potential having an entire system for health when it ultimately goes unused in the most dramatic of damage scenarios.
Plus I can speak from personal annoyance at having lost a vehicle - get this, to a leaf block at that - when it would've been preferable to simply require a repair after hitting the apparently-titanium tree branch. (Not that we had health back then, but that's besides the point...)

TL;DR Why vehicle go boom? Just set health to 0.

I'm going to mark this as potential, but I want to see packs add animations for them being destroyed before I code this. Otherwise, users will be confused. Snail, this means get to droppin that OCP release you've kept in the oven for over a year...

Heeey! I've got me destroyed animations, even if they are a bit rudimentary! I just don't test 'em too often... you get a boom, some flames and smoke, then you're left with a vehicle that's dropped to the ground.

Oh, I know you have them. And so does UNU. But the older packs don't. TRIN and OCP being the two main ones that come to mind for me. I hate to have the vehicles just stop working without any visibile change. Flansmod makes parts fall off. MCHeli makes the model turn black. Those packs? That wee little number at the top turns red.

Wha!? Since when the crap did UNUs go boom? Also I might be mistaken but Trins will at least drop to the ground nowadays, though if that's not sufficient then I can bug them into adding more FX.

Man, I hadda total too many UNUs to test that... I couldn't seem to find any indicators that they're damaged or totaled (aside from red text), nor are there even any variables in their JSONs to detect it.
Here's how Trin's looks, with the (repaired afterwards) totaled vehicle being closer to POV.

P.S: ):

Well, in that case, it's even LESS likely that a user would notice an issue. I'mma gonna decline this feature request due to the low utilization of health for totaled animations as previously discussed. If everyone gets with the program, then we talk.

We had a discussion on Discord about this a good while ago...

"Im not sure what channel it was but a couple of PAs discussed this topic before.
There was the idea that ground based vehicles receive damage based on block collision tied to speed.
If a collision does damage that would reduce vehicle health by 150%, the vehicle should blow up.
Useful params for this would be:

isVehicleCrash: true - for particles and sounds. System detects, which hitbox crashed into a block and, depending on what the parameter was out on, plays a sound/spawns particles at the hitbox Center.

totaledSpeed: X (m/s) - totaledSpeed defines the speed at which a full health vehicle would receive 100% damage.

crashDamageThreshold: X (m/s) - defines, what the minimum speed is required in order to do crash damage.

totaledSpeed and crashDamageThreshold work together in the way that the system calculates what speed equals what crash damage.
So if totaledSpeed is set to 100ms and threshold to 50, crashing into a wall at 75ms would result in 50% damage
Same logic should be applied to parts.
If a wheel has totaledDamage 10, it pops when impacting the ground at 10 ms, when hitting the ground at 15ms (150%), it breaks completely"

I know it's from last year but I sorta forgot to respond. I do agree with most of this (although it may be outdated given I'm still barred from seeing these useful sorts of conversations) however I disagree with this:

If a collision does damage that would reduce vehicle health by 150%, the vehicle should blow up.

For what it's worth I don't think we should be entirely poofing a vehicle if it crashes, anymore, period. Either that, or I'd say it should be manually enabled on a per-JSON basis for vehicles that could even go fast enough to manage a collision of that type, with a frame that likely won't survive said collision.