Following was obtained during observation of strange outcomes of test for CORE-3554, for a long time.

This test performs two EXECUTE BLOCKs.
First of them executes pretty long statement (~32K length), but this is allowed in FB 3.x+ and thus it must finish OK, i.e. producing only STDOUT (single line: "N 32739").

Second EB tries to execute empty string as statement and thus must always fail (issuing STDERR).

The question of this ticket is about this STDERR content.

If we run only 2nd EB (i.e. comment out 1st of them) then STDERR looks like this:

1  Statement failed, SQLSTATE = 42000
2  Execute statement error at isc_dsql_prepare :
3  335544608 : Unexpected end of command
4  Statement :

But if we run both EB then result of second (which tries to execute empty string as statement) in almost 100% of runs will differ from previous: it contains other gdscode for "Unexpected end of command" and, beside of this, two lines above it with another gdscodes (335544569 and 335544436):

1    Statement failed, SQLSTATE = 42000
2    Execute statement error at isc_dsql_prepare :
3    335544569 : Dynamic SQL Error
4    335544436 : SQL error code = -104
5    335544851 : Unexpected end of command - line 1, column 1
6    Statement : 
7    Data source : Firebird::localhost:....

Putting COMMIT between 1st and 2nd EB has no effect: result is the same.

I have no guess why this occurs, but this can be seen only when FB is run as Classic. And only in Linux.

Scripts (.sh and .sql) in attached file illustrate this: it runs many times .sql and check its STDERR.

To reproduce problem: extract both files from "loop-core-3554_-_wrong_stderr_in_almost_all_cases.7z" in /var/tmp, then open "c3554-loop.sh" in editor and adjust variables FB_HOME, DB_NAME, ISC_USER and ISC_PASSWORD to your environment.
Also, you may need to increase value of variable 'ITER_LIMIT' (especially for CentOS-7), now it is 1000.

::: NB :::
.sh script expects WRONG result in STDERR (i.e. presensce of line "335544436 : SQL error code = -104"), and this is so in amost all cases.
But if line "335544436 : SQL ..." is absent then this loop is terminated with message "@@@ OUTCOME BECAME DIFFERENT @@@" (which means that STDERR became CORRECT).

On Debian (version "10 (buster)") this script usually finished quick enough:

# ./c3554-loop.sh
Server version: LI-V4.0.1.2521 Firebird 4.0
Iter 1 completed OK
Iter 2 completed OK
Iter 3 completed OK
. . .
Iter 372 completed POOR: SQL -104 found in STDERR.
Iter 373 completed POOR: SQL -104 found in STDERR.
Iter 374 completed POOR: SQL -104 found in STDERR.
@@@ OUTCOME BECAME DIFFERENT @@@ Check log:
--------------------------------
     1
     2  N                               32739
     3
     4
     5
     6  Statement failed, SQLSTATE = 42000
     7  Execute statement error at isc_dsql_prepare :
     8  335544608 : Unexpected end of command
     9  Statement :
    10  Data source : Firebird::localhost:/var/tmp/fb40tmp/examples/empbuild/employee.fdb
    11  -At block line: 4, col: 7
    12  After line 27 in file /var/tmp/c3554x.sql
--------------------------------

On CentOS it is much more difficult to get the same result (I've checked on 7.8.2003).
But after 3..4 attempt you may get the same.

PS.

This result can be seen for a long time on FB 3.x, 4.x and 5.x for CORE-3554 in firebirdtest.com
(but not for every subsequent run of this test; the nature of its outcomes seems to be random).

Unfortunately, I could not understand properly this results (during test implementation) and they are displayed there in "reversed" view: "P" means that test has finished WRONGLY, "F" - that CORRECT :-)

PPS.
The length of statement which is executed in the 1st EB does not matter: I've get the same result when run statement with "normal" length about 100 characters.