Program doesn't execute the same after save() in flash

Pretty much sums up the application part...

Regarding the restore from FLASH: it is everything as it was at the moment when save() was executed - not just the global vars - including the cache which holds the modules (and the config of the MC, such as ports, etc... More about that later).

Think of save() as the hibernate function some PCs have (or a computer VM): everything is 'saved' when going to hibernate. When coming back, everything is restored (with the PC it is every time you put it to hibernate and restore is from last saved state, with Espruino it is just the one time of save and the restore is always from the initial save.

One thing you left out in your list: BEFORE a) happens, chip configs - most importantly, port configs - are restored...

And to be accureate, var moduleVar = require("xxx"); is a personal practice... You could actually leave that away and use anywhere where you need the module `require("...");, because the cache that holds on to the module code is part of the RAM and saved / restored as well, and require() is the vehicle to get to the modules in that cache... . The use by a variable is more general (and can hide different ways of that 'require("...");', because when the module is actually a class, for example, a Person class, and you 'store' it in the variable var Person = require("Person");, then the use later on in the code is much more obvious, for example, var person1 = new Person(...); and var person2 = new Person(...); Notice the casing: classes start with UpperCase, variables start lowerCase - both are camelCased. This is a good practice to be clear about what is a Reference to a Class and a reference to an instance of a Class.

Good practice is not to save something dynamic, such as a timeout or interval. Therefore setTimeout(...) and setInterval(...) should never be executed on upload... put them always into the onInuit(){...} or E.on("init",function(){...});. Same is for creating a connection (latter not totally true, because Wifi settings can be saved too and Espruino automatically connects using the Wifi settings on startup...).

(Personally - and in general - I do not like the fact that hardware initialization/restore - such as port modes - is part of the power up; but with well defined power-on behavior and resource strapped Espruino, it is very helpful - in various ways...

Btw, you are thinking 'Arduino' style - no offense to be taken here... The coding model is totally different... (Espruino almost bents itself over, because it has now an option in the setting that lets it almost behave the same: after upload completion, the upload makes a save, and then behaves like the invocation of onInit() or invocations of E.on("init",...).