Having been involved in the WG14 discussions on this topic:

The issue is that there is a contingent of users who complains about cases where the return dynamically can't be hit but that isn't obvious statically. Consider something like this:

  int do_something(enum meow koala) {
    switch (koala) {
    case enum_val_1: return 5;
    case enum_val_2: return 3;
    /* etc., covering all the enum values */
    }
  }

Should this be required to diagnose? That's the sticking point.

In some cases it's easy to diagnose, but in others it amounts to the halting problem, so it makes sense that the requirements are loose. Like many things, the standards body considers it a "quality of implementation" issue for compilers to be friendly.

It seems like something that could have been trapped right in k&r.

Was it ever even theoretically under any circumstances for any reason intended to be able to write a stack of functions with no returns that just fall into each other like assembly? I can't believe it.

So it seems like something even the very first compiler could have cought right in an early parser pass or stage.

But I also decline to believe I have a better idea about something than K or R, so there must be a non-triviality I don't see. I mean goto() exists in the language so ?

... I guess simply detecting the end of a function, or detecting that the process reached the end of a function, isn't a good enough definition of the problem. You can have any number of returns or gotos in the middle that you are always supposed to hit, and intentionally no return at the end because instead you have an assert or a goto.

assert you should never get here, goto error, goto not error but just next step, etc. They might or might not be error conditions that the process reached that spot, but it's not an error that the code doesn't end with a return.

I think I was using C++14 at the time...

Another issue that happened in the same project is that for some reason whenever I compiled it with a regular C++ compiler, field writes were disappearing into the abyss. I think I actually never figured that out because it was literally the same object at the same memory address, there were no other threads and yet when a subroutine returned after writing the field, the write disappeared?? The strangest thing is that Emscripten's C++-to-WASM cross-compiler worked perfectly fine with the exact same routines. I wonder if the compiler I used simply had fuckass issues, it was an oldish (by modern standards) Apple clang from like probably macOS 10.14 or so.