(Edited to describe a change under consideration which addresses this behavior.)
The CLI's line collection process applies just a few rules, which can be summarized as:
1. If the line begins with '.' and is the first since the last SQL or meta-command was processed, then it is a single-line meta-command and processed as such.
2. If the line ends with ';' followed by nothing but whitespace<sup>a</sup> and is not within an SQL construct within which that character is considered part of the construct rather than a statement terminator, then the line together with its predecessors (that were not meta-commands) is submitted for SQL execution. (prepare, step with output, finalize)
In your example, the "--" which begins the line, per all SQL standards, makes that and the remainder of the line, whatever it may be, a comment.
It would have to be a special cased handler that would treat ';' as a SQL terminator only if it appears at the end and outside of all lexically delimited constructs<sup>b</sup> **except** end-of-line comments.
I do not see how the present behavior is weird. Should an end-of-line semicolon within a block comment also terminate the SQL to avoid this weirdness?
(Added via edit:)<br>
This additional summarized rule would cure your script problem and should be harmless in all circumstances I am imagining:
\3. As non-meta-command lines are accumulated, at any time that they constitute a complete SQL construct which is nothing but whitespace<sup>a</sup> the accumulation is discarded, the primary prompt is issued (if in interactive mode), and line processing reverts to the state where either meta-commands or SQL (finally ending with ';') are accepted.
Comments on any difficulties arising from this approach are more than welcome.
a. In this context, "whitespace" includes the usual not-dark characters and SQL comments.
b. The "lexically delimited constructs" are quoted strings and identifiers, and end-of-line or block comments.