All smaller than int types are promoted to int before calculations are done. I was wrong that uint32_t is smaller than int though.

For an actual example:

  uint32_t combineTwoUint16(uint16_t x, uint16_t y)
  {
    return x<<16 | y;
  }

If int is larger than 16 bits, then this is technically undefined behavior in the case that x is greater than 2^15 as it's signed integer overflow.

Well the solution is simple:

  return (x+0U)<<16 | (y+0U);

Would it be insane to have a inline library for every arithmetic operation, that would handle such cases and offer addition optional functionality?

The intersection of people who are willing to rewrite all their arithmetic to use such a library with people who are not willing to switch to a non-C language is rather small.

Keep the old code, instead just start using it for new one.

Most projects still written in C are those that make extensive use of C libraries. Making the application code immune doesn't actually reduce the vulnerability surface much - much of the vulnerability comes in the libraries the application calls.

Use it for new code. Libraries are written too.

Libraries are usually older than the applications that use them. New libraries can be, and often are, written in new languages.

No, sadly. In some cases (floating point) what happens is even implementation-dependent (though queryable with FLT_EVAL_METHOD).