No. Lots of frameworks ecosystems and languages break backwards compatibility all the time. Node stuff won't build a year from now even with the same lock file.
In the case of the "internal dependency" one, plenty of people regularly patch stuff in NPM and keep the same version number.
funny enough i have a simple but old app created with “create react app” that doesn’t run on anything other than node 16 and below.
Recreating the whole outdated stack is often doable, but it's really time consuming and often feels more like archeology than Computer Science.
What you really want is strong backward compatibility so that Node "30" still manages to build projects from 10 years ago.
how confident are you that Node 18 will run on whatever platform you're using then? or will you be stuck on a 2023 OS image also? will all the deps be available? will the many layers of tooling still work? will they work on Node 18, or will you need to get Node 18 and Node 2033 running in the same space? etc etc.
it's already a nightmare running things a year or two apart in time in the Node world, I would guess in 2033 you'd need an entire frozen-in-amber VM image with all tooling also frozen in the same amber/.
It actually worked, remarkably, but I wouldn’t trust it on production.
Software is either maintained or abandoned. There’s no “done”, as much as we want it to.
I seriously doubt Go is advertised as forward compatible or that it is such in practice. Just like any similar programming language, they depend on system interfaces, and those change, albeit at a slow rate. If all older versions of Go aren't on life support, then some will become obsolete over time.