> I think this change is no problem.

Thanks, and thank you for looking reviewing this change.

> There is only one situation that a problem may occur. Write code with SQLite
> 3.8.7.2+ (2014-11-18), and run it on 3.7.15 (2012-12-12) ~ 3.8.7.1-, but
> this situation may be difficult to happen, we can note this situation in
> doc.

How realistic is this scenario? If you compile with, for example 3.14.0 or newer, you'd link with sqlite3_trace_v2, not sqlite3_trace, so the loader would prevent you from running with anything pre 3.14. AFAIK, we've never had such problems.

> More securely, if run on SQLite 3.8.7.1-, and encounter
> SQLITE_ABORT_ROLLBACK error code, a prompt can be given to explain the
> reason.

You already get both an error message, an (extended) error code. That should be sufficient.

> Also note that the current main branch is buggy. If don't adopt this change
> or revert this change later, don't forget to fix the bug of msg407185
> (`pysqlite_Statement.in_use` flag is not reset).

It is a change of behaviour of the internal machinery. Does the change lead to wrong results (duplicate rows, wrong rows returned, no rows returned)? Corrupted/garbage data? Non-deterministic behaviour? Does any of the API's provided by sqlite3 not behave according to the documentation anymore?

NB: I plan to get rid of the in_use flag long before the beta sets in.