Well no, that was my point. While it's the correct thing to do (from a security point of view), it does not lead to 100% identical code being executed.
In a development build, each script is compiled into a single shared library for hot-reloading, fast iteration times, etc.
In a retail build, all scripts are compiled into the game executable, so the builds that go through QA are also what ends up in the user's hands - 100% identical.
Not only is (this is rather pedantic since it should hopefully make no difference, but who knows) the function binding and calling different between "same executable" and "in a shared library", but also, more importantly, you can expect a modern compiler to perform whole program optimizations on "same executable" code that are simply impossible across shared modules where the respective part isn't present at link time.
Hopefully, you never see a difference (and I guess most of the time you won't), but you can never be 100.0% sure (only 99%). The things that are most nasty to debug are the ones where it works fine on one machine, but doesn't on another, and then it turns out that's because they were running kind-of-the-same code, but not exactly.
Ok, if I understand you correctly, you're talking about the difference between a development build and a retail build?
If so, then well, yes, that is true for every game I've ever worked on. Development builds usually have lots of features which are stripped out in retail builds.
Console games always had the "happens only when being started from the DVD"-kind of bugs, so debugging retail builds without symbols was the way to go.
Or did you mean something different? But then I didn't get your point, I guess :-/.