The difference is that after the fact--ie. once the program is implemented and you can try a scenario and see empirically what happens--what happens is no longer undefined. But it remains unspecified.

Once you can create circumstances for which the specification does not define the expected effect, outcome or result, you can then see what actually happens. And once you know what actually happens, it is no longer undefined; just unspecified.

It is actually very rare that for any given set of circumstances, a computer program will result in a random outcome. In general, for a given set of inputs, you will get the same set of outputs/outcomes. Were that not the case, the whole basis of testing and test driven development wouldn't work. It is the very basis of debugging--hence the maintainers plea for minimum reproducible testcases. It's not always easy to determine the full input set, but they're the bugs that are most interesting--provided time pressure isn't too high.

Hence, it is usually possible to say that for build X of Y; doing Z will result in A. Even though it may not be specified; and that it might change with platform, implementation or build; and as such, should not be relied upon.

What's that talking of "behavior" concerning computers, anyways? There's no such thing. Computers don't "behave", since they don't choose one reaction or another out of a set of possibilities at free (or bound) will, pondering the effect of that choice. Talking of "behavior" when it comes to computers is an anthropomorphism,

Using the word behaviour in conjunction with computers is not anthropomorphising. Behavour can be simply defined as "the actions or reactions of an object or organism".