The spec says:
"Changing the src, type, charset, async, and defer attributes dynamically has no direct effect; these attribute are only used at specific times described below (namely, when the element is inserted into the document)."

This doesn't seem to be entirely true. I tried implementing src/async/defer freezing upon insertion into the document, and the results were wrong.

There are three interesting cases:
 1) The parser parser a script element from the network stream. A timeout (or whatever) changes src/async/defer between the time the element is inserted to the DOM and the time the end tag is parsed (and the script is run). In this case, the timeout (or whatever) is racing with the network, so there's no point in trying to make this case nice for the timeouts.

 2) The script start tag is document.written. Then the script doing the document.write changes the src attribute on the script element that got created by the document.write. Then the end tag is document.written.

 3) The special case where a script element has neither non-space content nor the src attribute.

In case #1, the effective values of src, async and defer need to be frozen when the element is inserted to the tree so that the asyncness or deferredness of the script is solely determined by markup and cannot be changed by scripts before the script is run. If the deferredness or asyncness were changeable by scripts, there'd be a case where DOM scripting would need to feed back into the parser, which would be bad for off-the-main-thread speculative parsing. (If the deferredness/asyncness is determined solely by markup, a speculative implementation doesn't need to speculate on the script, since it knows the script can't do document.write with a defined insertion point.)

The old parser in Gecko doesn't allow scenario #2 (I don't know by what mechanism), so the exact behavior in case #2 probably isn't Web compat-sensitive. For me, it would be the easiest to perform the same freezing in this case as in case #1, but I could see an argument why it would be less surprising not to freeze in case #2.

When cases #1 and #3 coincide, the spec sentence is wrong. In that case, subsequent additions of non-space content or a src attribute cause the script to run even though it was originally parser-inserted. It seems to me that if the script didn't got marked "already started" when the parser tried to run the script upon </script>, src/async/defer need to be thawed so that another script may cause the script to run at a later time (contrary to the spec sentence claiming that setting src dynamically has no effect after the node has been inserted into the document).

I'm requesting that the spec say more explicitly what I described above about cases #1 and #3. I'm not quite sure what I should request about case #2, but provisionally, I'm requesting that it be handled like case #1, even though case #2 doesn't strictly really need the freezing.