Ideally, something like the Fixpack for existing areas, whereas modders who add new areas can flag them right off the bat in the area files. And here's an advantage (for modders anyway) you may have overlooked - we can give those "unknown" bits in NI and DLTCEP useful labels (something impossible with ADD_AREA_TYPE).
This doesn't belong in the Fixpack (and I can hear the objections already). I don't think the NI guys will include it either.
Additionally, maybe half of the areas that need to be flagged are from megamods and such, and we both know they'll never be updated on account of this. An includeable resource that makes one or more new area types available would be the way to go.
Personally I prefer ADD_AREA_TYPE because that way I don't feel I have to provide all the area types (the complete system). I can simply release the two area types I have and leave it at that. But if you, or someone else, provide the rest I guess I can go along with it.
Well, they can talk about it here or elsewhere (not sure if this is the best forum, but cmorgan was the first to bring it up - or maybe berelinde; hard to tell from that first post). With the exception of what you said about strongholds, those other types should be fairly straightforward yes/no questions, no?
That is a fairly bad case if you ask me. I don't see the need for any mod incompatibilities just on account of area types.
I can promise you it won't be that simple in practice. People are quarrelsome and don't agree. Your proposed system would be vulnerable to disagreements. If someone decided to launch a different scheme, it would pretty much be straight-off incompatible with yours, or any other static system. As such, any two mods that use different systems would be incompatible simply because they used different systems.
ADD_AREA_TYPE is less vulnerable to incompatibilities. You could have different-but-same area types, you just couldn't have more than 8 new ones installed at the same time. And unlike a static system that simply assumed that bit N was type X, ADD_AREA_TYPE would fail loudly once it hit an incompatibility (a static system would result in a lot of weird, silent errors on incompatibilities).
One more thought - hitherto, I think we've only been talking about areaflag.ids and the area field at 0x48. If we need new area types, can we not also add to areatype.ids and use the field at 0x14? Right now that has:
1 TUTORIALAREAand also presumably
3 DREAMAREAMeaning we have 28 unused flags here. Probably not as dynamic as combinable bitfields in areaflag.ids but perhaps more appropriate for something like CANT_TELEPORT?
0x14 - areaflags.ids
0x48 - areatype.ids
Unlike areatype.ids, I don't think areaflags.ids is accessible from scripts.