It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus.

But, if you want an answer to your question:

You can learn to avoid undefined behavior in about 30 seconds.

If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.

Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized.

> You can learn to avoid undefined behavior in about 30 seconds.

Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.

Before you could assume...null pointer derefs will be trapped by the OS

Before when?

  Microsoft(R) MS-DOS(R) Version 6.22
               (C)Copyright Microsoft Corp 1981-1994.
  
  C:\TMP>type foo.c
  void main() {
      long q = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od foo.c
  Microsoft (R) Optimizing Compiler Version 5.10
  Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved.
  
  [...]
  
  C:\TMP>foo

  run-time error R6003
  - integer divide by 0
  
  C:\TMP>type bar.c
  void main() {
      long far *p = 0;
      long q = 0;
      *p = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od bar.c

  [...]

  C:\TMP>bar

(system hangs)

In DOS you always had to manage your expectations, not sure what you're trying to prove here?