All the most popular unlock hack does, and possibly all the unlock hacks, is completely overwrite the baseband data. it's down and dirty, shotgun approach. You have to use something like Jailbreak to even do the unlock, but that's incidental, really. Frankly, it seems with some of the comp. sci. academic credentials of the people who created the unlocks, they should have known it was not only dangerous but probably doomed from the start, even had Apple not aggressively responded.
I totally agree with you that how Apple and we are defining the term "firmware" is highly relevant and makes a big difference on what exactly they are doing. I assume we agree that firmware "patches" and "updates" are technically misnomers as no one usually goes in and writes over little areas of firmware flash here and there, but rather re-flashes the whole puppy. But a sacrosanct segment of firmware containing, for analogy's sake, the "iPhone BIOS" would not be touched by a complete re-flash of the segment of firmware handling mid-to-high level operations. The GSM baseband and various other virtually never touched -- may have never really been expected to *ever* be touched unless the carrier changed something on their network -- low-level settings and the rock-bottom bootstrap code would reside here, and indeed "walling off" these things from even Apple's own firmware re-flashes would be a good design decision. That way the designers themselves don't accidentally brick their own device with errant update code because they don't ever touch the area that would brick it.
Also in favor of your argument for a firmware Holy Ground is the fact the restores, which are full firmware re-flashes *do not* relock. Excellent point. Further in favor of your point -- oh hey, don't stop me from dismantling my own case for you to save you the trouble -- is that the rushed-up relocking attempts that hit last night aren't consistently working, meaning trying to rewrite the old baseband data is failing (some people are reporting no relock, some are reporting bricks). Meaning Apple had to work out a way to rewrite the proper baseband data that doesn't fail because they intend to relock. And it's possible that whatever you have to do overwrite the baseband data after it's already been overwritten will brick the phone. Someone mentioned that maybe there's an upper limit on the number of times you can overwrite the baseband. Like the SuperDrive in my Mac laptop: I can set and change the region code, held presumably in a writable firmware segment -- there's even a legitimate Apple-provided way to do this -- but I may do it only so many times, I think between 3 and 5, before the last one I set, that's my region code on that drive forever. It's an artificial limit, of course, to prevent SuperDrives from becoming essentially region-free DVD video players. Perhaps the upper limit on baseband overwrites is 1. And unlike the DVD drive, which won't brick, just won't change regions again over the limit, there's no fail-safe built in for exceeding the limit: it just bricks, maybe because you smash the bootstrap code doing the second baseband overwrite. (Also, by "permanently inoperable" Apple may not mean it will outright brick, that it won't iPod or Safari, but that it will never work on a GSM network again, even AT&T's; but if relocking requires legitimate reactivation and since you'll never get on a GSM network again, and we all know all iPhone's features require activation, it's tantamount to bricking). A low limit would explain why overwriting the baseband to unlock the iPhone doesn't brick it, but Apple overwriting the baseband to relock it does brick it.
There's a potential nasty future problem with this concept, though. If the upper limit is 1, then if Apple with this update overwrites the baseband, even my unhacked, never unlocked, AT&T iPhone-contracted iPhone will have its baseband overwritten. Should Apple ever need to do this relock again, they will have burned my single baseband overwrite this time, and they'll brick my legit iPhone the next time they do it. Of course they can always examine the baseband and if it passes muster, they skip the part of the update that performs the overwrite. Probably this time around a simple checksum on the baseband data would do it. In the future, someone will probably figure out how to unlock with a baseband overwrite that equals Apple's proper baseband data checksum, so they'll have to come up with another way to verify that it's legit baseband data.
The only argument I have right now for my case is the iPod firmware updates -- uninterrupted, perfectly executed updates -- used to brick some iPods, indicating that Apple was indeed blasting all the firmware and if some unknown, possibly random hitch occurred during the process there was not a bit of stable bootstrap code in firmware left to boot the iPod to a stable enough condition to at least be recognized for a restore. But this has seemed to have stopped happening by at least the video iPods, so that argues for your case that they've segmented a hands-off region of firmware that updates don't touch.
Anyway, it's an intriguing mystery.
Do you know this for sure? I'd be surprised if Apple updated the low level firmware with every software update-- it's too dangerous. When you design a product that can accept software updates, there's typically a portion you keep in a special sector of flash, that you don't erase when you update everything else. Among other things, that's the bit that tells the processor how to accept the new software (in this case it communicates with iTunes). You don't touch that because if a standard software update fails for any reason you want the lowest level parts to still work so you get a second shot at it. If things get hopelessly mangled, you do a restore and get back to where you started.
The definition of firmware, software and drivers is all kind of vague on an embedded device, so Apple may call different parts different things, but true firmware updates, in the sense I'm referring to, are usually few and far between. This isn't handled by a "restore", it's a separate operation.
It makes sense to keep the SIM handling in this same area because you don't want to risk a software update disconnecting you from your network. Since there's only one approved network, it's much safer from an engineering perspective, to just never touch that bit of code.
I haven't looked into how the unlock hacks work, specifically, but I've designed this kind of stuff before so I'm simply explaining what makes sense to me. The fact that the unlock hacks are "restore resistant" further supports my explanation.
