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.

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.

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.

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.

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.

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 :-/.

Also I have come to understand that if you want your game to be moddable use of traditional scripting languages might be a good idea ..... One question couldn't one script in c++ then expose the necessary functions and variables to a scripting language in case someone wants to mod thegame or would that be too much work for nothing

Most of this depends on the size of the project and size of the team. How much work it is and how much it helps you also depend on the size of teams involved.

A scripting system is just a secondary method for programming the game. The language used for the scripting system is irrelevant.

The primary benefit of scripting languages is that you can make changes to the scripts without rebuilding the game or game engine.

For a small project with individuals adding scripting languages makes no sense, you are building in support for a secondary programming method to be used by one or two people. For such a team spending work-months or even a work-year is a huge cost with almost zero benefit.

For a large project with tens or hundreds of people adding scripting languages makes more sense. People can vary their scripts without going through the long and slow build system. As team sizes increase and build times increase, the benefits of scripting languages increase rapidly. If there are 30 people working on scripts that means 30 people not rebuilding the code. Consider if it saved an hour a day * 30 people * 200 days, you're looking at three work years lost to rebuilding code; spending a work year or two work years implementing a scripting system is far cheaper than three work years lost. More people or more time involved means even better cost/benefits improvements.

For plug-in style mods, the benefits are basically the same. It is still a secondary way to program the system. That can be a selling point on its own, but only worthwhile if the game has broad distribution and is worth the time to implement, test, and debug the secondary programming method.