The standard says:
1.3.24 [defns.undefined] undefined behavior
The last sentence of the note you quoted explains the may
in its first sentence:
Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.
Thus, may is quite correct.
Anything not defined is undefined, though there are many ways it can be defined (even if it is only slightly constrained).
Also, as notes are not normative, they cannot define behavior.
However, how can the standard say something is undefined behavior without explicitly saying so?
Because that's what undefined means. What happens has not been defined. The standard defines what is expected of a valid program, it doesn't attempt to list every conceivable invalid program and say "this is undefined, also this is undefined, also this is undefined".
The standard doesn't specify what happens if you set fire to your computer while the program is running. That doesn't mean it's well-defined. It's clearly undefined.
Literally anything can happen in a program and it is assumed that it is not undefined behavior unless said so by the standard.
I'm not sure what you're trying to say here, but it sounds 180° backwards.
Does this mean a non-standard program is undefined behavior by default?
What is a "non-standard program"?
Formally, anything which the standard doesn't define is undefined behavior. How is it defined, if the standard doesn't define it?
Practically, there are a couple of things which are taken as
given; if the standard defines a behavior, for example, an
implementation cannot add additional observable behavior. (I.e.
in a statement like a = 2 * a;
, an implementation isn't
allowed to modify anything but a
, even though I don't think
you'll find an explicit passage to this effect in the standard.)
But that's about it. If the standard doesn't define it, it's undefined behavior according to the standard. (An implementation may provide further definitions. In fact, all do.)