This is a minefield. If anyone has a use case for it, I'd *love* to hear it, but to me it seems that proper reinit support will be a lot of work (now and in future maintenance) for no gain. You can always create a new connection object.

Consider instead deprecating reinitialization, documenting it as unpredictable & removing it in Python 3.13.


Here's another thing to test:
```python
import sqlite3

conn = sqlite3.connect(':memory:')
cursor = conn.execute('CREATE TABLE foo (bar)')

try:
    conn.__init__('/bad-file/')
except sqlite3.OperationalError:
    pass

cursor.execute('INSERT INTO foo (bar) VALUES (1), (2), (3), (4)')
```

And here's the kind of behavior that should be specified (and tested), and might even change to make more sense:
```python
import sqlite3

conn = sqlite3.connect(':memory:')
conn.text_factory=bytes
conn.row_factory = sqlite3.Row
cursor = conn.execute('CREATE TABLE foo (bar)')
cursor.execute('INSERT INTO foo (bar) VALUES ("1"), ("2"), ("3"), ("4")')
cursor.execute('SELECT bar FROM foo')

for row in cursor:
    print(row, list(row))
    break

conn.__init__(':memory:')
conn.execute('CREATE TABLE foo (bar)')
conn.execute('INSERT INTO foo (bar) VALUES ("a"), ("b"), ("c"), ("d")')

# Currently this uses the old database, old row_factory, but new text_factory"
for row in cursor:
    print(row, list(row))
```

We should also do a review of all places `connection` is used from Cursor, Statement, etc. to ensure everything continue to work with a different `db`. This can be done (and maybe you already did), but I'm also worried how well future maintainers can keep reinitialization in mind.

And all this will also need to be done for Cursor.