I was thinking that what might make a lot of sense is to let users mark sections of the code as atomic, meaning they must occur without being interrupted partway through. This is for solving the problem where the number of instructions per update runs out in the midst of trying to take physical measurements, so that there's a large "jump" in time between adjacent measurements that the script programmer didn't expect, throwing off the calculations.

i.e. this:

UNTIL 0 {
  SAMETIME {  // < -- proposed new keyword
    set prevVel to ship:velocity:orbit.
    set prevPos to ship:position.
    set prevFuel to ship:liquidfuel.
    set prevTime to time:seconds.
  }
  WAIT 0.0001.
  SAMETIME {  // < -- proposed new keyword
    set newVel to ship:velocity:orbit.
    set newPos to ship:position.
    set newFuel to ship:liquidfuel.
    set newTime to time:seconds.
  }

  // Now the code does stuff comparing the new and prev values..

}.

To a certain extent you can get this right now with an explicit WAIT, because you can WAIT 0.0001 just before entering the "SAMETIME" sections instead, but that depends on knowing that your statements all fit within one CONFIG:IPU, and being aware of the compiler details to know how many instructions your script commands become seems wrong.

As to the intended behavior under the hood, I was thinking of this:

• At the start of SAMETIME, put the program to sleep until the next Update tick, so the first line of the SAMETIME section is the first line of code executed in a new update. Also, set a runtime flag for "I am in a SAMETIME section right now" that will get cleared at the end of the braces section.
• When a SAMETIME is currently active, if you reach the end of CONFIG:IPU instructions before you reached the end of the SAMETIME section, then we do one of two things: Either we:
  • Issue a warning to the terminal stating that the SAMETIME section is too big to fit in one update, and continue behaving as normal - the program stops and waits for the next update tick. This would make SAMETIME into merely a sort of warning system. It doesn't force the code to exist in one tick - it just lets the script programmer know that it doesn't so they have to redesign their code.
  • Or, Ignore the normal rules and continue executing until the end of the SAMETIME section is encountered before finishing the update tick, even though that exceeds CONFIG:IPU. Thus SAMETIME becomes an enforcement on kOS demanding it behave like the programmer wants. This carries risk of stuttering slowness or even infinite hang, but we already have exactly that risk in how triggers execute, which don't adhere to any limit of instructions per Update().
• Nesting the sections: Inner SAMETIME sections would mean nothing at all since the outermost ones are already saying you can't go more than one physics tick within the code. They should be run-time errors (if starting a SAMETIME section when one is currently active, it's an error). (Because for them to be compile-time errors you'd have to examine the structure of all the functions being called and subprograms being executed from a SAMETIME section to find out if they contain SAMETIME sections.)

I'm not certain "SAMETIME" is the right keyword. It cold be INSTANT or FREEZETIME or NOUPDATE or SAMEUPDATE or whatever you want to call it. I'm open to proposals for better terms. I considered calling it ATOMIC, but I don't think it's a good idea to introduce novice programmers to the term ATOMIC, and have to explain it.