This reminds me of the terminology I learned for heart rhythms: regular; regularly irregular; and irregularly irregular. The first is the way a healthy heart beats. The second is unusual but the same in every cycle: a sign of something abnormal but not necessarily incompatible with a long life. And the last is unusual and inconsistent from one cycle to the next: usually very bad.

I wouldn't distinguish between undefined and unspecified myself. I think a definition is just a form of specification.

The phrase "the behavior of a feature" doesn't seem right to me. My reaction is that a feature doesn't have a behavior. Rather, the behavior is a feature. I would be more comfortable with "behavior X is a feature of Perl 6". But this is probably just my problem.

I would say, given the specification of some relevant circumstances, that "the behavior of Perl 6 is undefined" or "unspecified".

If one discovers empirically or by other analysis of an implementation that the behavior is or isn't consistent from trial to trial, this makes the behavior neither more nor less defined or specified. One implementation might behave the same on every repetition and another might behave as randomly as computers are able to. There are endless possibilities, none of which change the specification.

Is there value in specifying that some behavior that is otherwise unspecified is specified to be the same for every repetition with a given implementation but may be arbitrarily different for a different implementation? For one implementation the behavior might be to dump core and for another it might be to launch a missile strike on the demons of the day and for yet another it might be to flip the chirality of the universe - the only thing you can be certain of is that for each implementation, however it behaves, it will behave that way that it does every time - that, at least, is specified and therefore a certainty!! (update: else there's a bug in the implementation). My inclination is that there is not much value in this.