Your question mentions a lot of technology without much structure so I'll break it down technology by technology in order to construct a correct answer about where we are with the kind of mitigation technique you describe.
As you mentioned one such way to gain arbitrary code execution of an application is via a Stack Buffer Overflow. This is an attack where a stack allocated buffer can be overwritten with more data than the buffer is meant to hold as a result the stack is smashed with data which allows us to gain control of the instruction pointer.
One mitigation designed to help prevent against arbitrary code execution is the use of No Execute (NX). The idea behind NX is to mark memory pages as "no execute" this means that any code residing in NX marked pages will not be executed by the CPU. While this does not prevent Stack Buffer Overflows it does make gaining arbitrary control of the system more difficult due to needing somewhere to store our shellcode. (Simplification).
A bypass technique for NX is the concept of Return Oriented Programming (ROP) this is where we can use existing instructions in the application or loaded modules called "gadgets" in order to bypass NX by setting the required page back to executable. (Simplification).
The idea you are describing is as pointed out in the comments similar to Control Flow Integrity (CFI). At a high level this mitigation works by identifying which functions in an application are valid targets for indirect calls. In the case of CFG this is managed by the Windows kernel which maintains the state that identifies valid call targets and handles the logic which actually verifies the indirect calls. CET is similar however it is implemented in hardware and uses the concept of a "shadow stack" which stores CPU-stored copies of valid return addresses. There are many implementations of CFI each vary slightly but all aim to solve the problem of ROP chains being used to bypass NX and other mitigations.
It should be noted that none of this stops stack overflows, they can still exist in code as in, the bugs can still be present. But by stacking exploit-mitigations such as NX, ASLR, CFI, Stack Cookies it makes such a vulnerability significantly more difficult to exploit.