Sorry, Martin, I simply disagree. [But to be clear up front: I'm still against default values in schemas and think we should get rid of them. That does *not* mean necessarily mean I think we should get rid of <defaultVal>, however.] First, to be sure, even if I agree it (@part and its default value) is broken as designed, it has been broken in exactly that way since at least P2. To rush to repair because "we can't possibly allow the situation as it [is] to continue" is silly. We (writ large) have allowed it to continue for well over 2 decades. But more importantly, it's a change that simply requires us to go through a deprecation process and warn users ahead of time. It breaks backwards compatibility. Yes, I agree, I don't think there is anyone out there using it in a way that will be adversely affected, but I think the reason we have Birnbaum principles is in small part because it's not for us to say. You were charged with making a list of attributes that make use of <defaultVal> so that we could examine them and decide what to do next, not with hacking them out of P5 (at least, not yet). Control your anger, master Jedi, lest you be turned like a Padawan who has lost sight of Birnbaum.
They can't possibly be using @part="N" to say "I can't tell if this is a fragment or not", because it _also_ simultaneously means "not a fragment". We're in a situation where the very definition of the value (as it was before I fixed it) was completely useless, because it had two contradictory meanings at the same time. Anyone who was using it for either meaning was both right and wrong at the same time, and no-one could draw any conclusion from the presence or absence of that attribute value.
If you'd like me to check with TEI-L to see if anyone actually was using it, I'll happily do that; but we can't possibly allow the situation as it was to continue.