Ok, I did some digging and figured out the problem

The command execution changed so that when you run a command while you are handling a command, the requested command gets put on the pile allowing the current command to finish.
Its a design choice but a way cleaner path to execute nested commands.

This impacts situations like
/script run run('setblock ....')
cause setblock will be run in a context of running the 'script' command

It has nothing to do with threading.

The issue can be mitigated by not running commands from commands, for instance this works:

/script run schedule(1, _() -> print(player(), run('/fill 200 100 200 201 101 201 stone')))

as well as calling run() in tick event or anywhere else but /script run/invoke

Hey there, my deepest apologies for the delayed response;

I had missed the fact that this bug would only occur if it was called from another command, so this problem scope is more limited than I first thought, thank you for the added explanation and details;

I believe keeping run_cb() (possibly renamed to run_async() as you mentioned?) could still be good for usages in command ran contexts (notably custom script commands) without the need for a workaround or places where retrieving the first error message is necessary (although that would be quite a rare edge case)

(edited, had not seen the new commits, thank you for fixing the return code issue and updating the documentation)

I've reopened the pull request (#2036) with run_async(expr, callback) + documentation and small documentation changes/precisions for run(expr), but if run_async isn't something you're looking to add into scarpet feel free to close both this issue and PR 👍