I would expect that, given the way it's set up: no Experience id = remove or keep same; with Experience id = either add, update, or keep same. Note the conflation.
My suggestion is to make the experience operations (add, remove, keep) dependent on explicit operations, with a implicit removal for a special circumstance. The explicit operations would be: Add Experience to script, Remove Experience from script. These would be explicitly set via the client UI.
When a script is uploaded without an Experience ID, it means simply to keep same - with the exception of if the uploader does not have permission to put scripts in an Experience: say they bought the script or object with full perms, the Experience association will be lost. This circumstance should display a warning to the user upon opening the script that saving the script will cause it to be removed from the Experience.
So in short:
Connect Experience ID with script: UI control.
Remove Experience ID from script: UI control, lack of permissions at upload (checked serverside).
Maintain current ID or lack: basic script upload.
Note that this means that no Experience ID is expected to be sent with a script upload.
Again, I don't know the feasability: if there's no ability to differentiate between an upload that is an update for an existing script and an upload that is a completely new script, then my entire concept would likely take too much of an overhaul of the code and potentially break some assumptions in the system.