I'm sorry to do this to you, but a lot of of what you wrote just doesn't make any sense at all.

once a term is defined that the definition can't change.

What "term"? We're talking about defining behaviour--or rather not defining it.

Unless you are talking about the term 'undefined behaviour', in which case I would tell the prescriptivist that I have no desire to change the definition of that term--there's no point because it is nonsensical.

I'm attempting to persuade perlers to adopt a term for the situations where perl's behaviour is deliberately left unspecified, that actually describes those situations; 'Unspecified behaviour' seems to fit rather nicely.

Something that is unspecified and that is referred to as an "undefined" combination of language features

How could you possibly specify the behaviour of "an undefined combination of language features"? The best you could possibly do in this vein is to specify the behaviour of every possible legal combination of language features--and then say anything else is illegal and its behaviour is thus unspecified. And combinatorics says that is improbable if not impossible.

... is expected to be allowed to change, even within the same project's different versions.

Of course. I acknowledged that above.

By saying you have "defined" it, you're effectively saying that you've found out what it should do rather than what id did do.

But no. That's like saying that discovering that eating peanuts makes you ill, means that anyone eating peanuts will become ill. Defining (to describe, explain, or make definite and clear), what happens for a particular instance does not imply defining for all instances. On the other hand, specifying what should happen, by implication does apply to all instances.

And if, when a particular instance's behaviour is defined--through observervation, measurement or testing--it is found to differ from the specification, then it can be said to be exhibiting unspecified behaviour, but not undefined behaviour.

That's not the intent, I think, of the term "undefined behavior". An "undefined behavior" as the term is used is one that may be different in a different implementation, on a different platform, or in next week's release. It is both unspecified and the empirical result, while often possible to ascertain, is not to be taken as definitive. If there is no definitive semantic, then the construct is undefined.

I understand the intent. I'm saying that the term "undefined behavior" does not meet that intent.

And that's my bottom line. The term can only be understood to mean its intended meaning, if you have previously encountered it and have rote learnt to interpret that particular combination of those two words, when used in the specifications for a computer language, to mean that intended meaning. There is no way to arrive at that interpretation through logical analysis of the juxtaposition of the two words themselves. Even in context.

That precludes anyone making their first encounter with the term from understanding it, which is devisive. I see no sense in continuing to perpetuate a nonsensical phrase, that was wrong the first time it was written, just because it has been replicated in the interim without challenge. Especially when there are other, better, phrases that can be used.