well Adam, you might also be surprised to see pysqlite not doing very well on the *other* side of the equation either; that is, when it *begins* the transaction.  Issue http://bugs.python.org/issue9924 refers to this and like this one, hasn't seen any activity since 2011.  You might be interested in the rationale on that one, which is that python apps may wish to have some degree of concurrency against a sqlite file for an application that is doing all SELECTs.  

I am certainly in favor of a pure pep-249 approach that emits BEGIN on the first execute() call period, and never implicitly rolls back or commits.  

However, I disagree this should be enabled by default nor that there should not be any option for the old behavior.  I also think the "delayed BEGIN" feature should still be available to counteract SQLite's particular difficulty with concurrency.

If there is code that relies upon a bug in order to function, which would then fail to function in that way if the bug is fixed, then by definition fixing that bug is a backwards-incompatible change.   Python std lib can't afford to roll out a change that blatantly backwards-incompatible.   The issue regarding comments not being parsed unfortunately should also be a separate issue that needs to be fixed, as nasty as it is that pysqlite tries to parse SQL.

I disagree that most users are expecting SQLite's DDL to be transactional; transactional DDL is a luxury feature to many, including the vast numbers of developers that use MySQL, not to mention Oracle, neither of which have any transactional DDL capabilities.