I think the presumed inconsistency is related not to max_statement_time, but to sleep function.
max_statement_time is supposed to work the same way as KILL QUERY, and I don't think any of the examples above contradict it.
SLEEP, on the other hand, has admittedly non-obvious variations of behavior depending on certain factors:

When SLEEP() is the only thing invoked by a query that is interrupted, it returns 1 and the query itself returns no error.
...
When SLEEP() is only part of a query that is interrupted, the query returns an error.

Do you want to request change in behavior of SLEEP?

Here SLEEP is a part of the query with other item in SELECT list that was interrupted:

set statement max_statement_time = 10 for select sleep(12),version() from mysql.user limit 1;

and there is no error. But with LIMIT 2:

set statement max_statement_time = 10 for select sleep(12),version() from mysql.user limit 2;

there is an error about interrupted query. Same query, but the result (documented result of SELECT(), 1 vs error) depends on number of rows selected. I think this is inconsistent. I do not want to change SLEEP() behavior, but I expect error in both cases. Query was interrupted, and SLEEP() was not the only item in SELECT list.

I understand and I don't disagree that it appears inconsistent. My point is, it's not new and it's not related to max_statement_time, it's just how SLEEP works in regard to any interruption. If instead of max_statement_time you'll run KILL QUERY manually from another connection, you'll get the same result. So, whatever change it might require, it won't be on max_statement_time side.

The description of SLEEP is pretty vague in this regard, I won't be surprised if further analysis shows that LIMIT 1 internally falls into the "SLEEP() is the only thing invoked by a query" category (whatever it is supposed to mean), and LIMIT 2 won't. I suppose we can wait for the analysis and then discuss whether a change in behavior is desirable.

Assigning to serg for dispatching, I suppose anyone can check the code and say "oh yes, it works as designed".

As explained above, it has nothing to do with max_statement_time.
In the essence, the question is why in the test below the first reap returns a result set, and the second reap ends with an error:

--connect (con1,localhost,root,,)

--let $con_id= `SELECT CONNECTION_ID()`

--send select sleep(10) from mysql.user limit 1

--connection default

--sleep 1

--eval kill query $con_id

--connection con1

--reap

--send select sleep(10) from mysql.user limit 2

--connection default

--sleep 1

--eval kill query $con_id

--connection con1

--reap

connect  con1,localhost,root,,;

select sleep(10) from mysql.user limit 1;

connection default;

kill query 6;

connection con1;

sleep(10)

1

select sleep(10) from mysql.user limit 2;

connection default;

kill query 6;

connection con1;

bug.t3                                   [ fail ]

        Test ended at 2018-12-28 18:05:01

CURRENT_TEST: bug.t3

mysqltest: At line 19: query 'reap' failed: 1317: Query execution was interrupted