System.Data.SQLite

If you are Cloning connection (or using such constructor) it doesn't cloning the password which is written outside of the connection string (by SetPassword() method). And when you are cloning open connection - you don't have a time to set password on cloned connection, because it would be opened inside Clone method.

The purpose of SetPassword() is to be a more secure way of passing the password to the connection.  If I saved the password in memory, it would defeat the purpose.  If you don't care about the security that much, then put the password in the connection string, and it'll be passed along to the clone.

Well, I'm totally agree with your approach.
But in that case we need a Clone which will accept the new password. ICloneable.Clone() can't be changed, but new constructor (accepting password and old connection) would be good solution. Otherwise (and when it's not red marked in documentation and visible only from source) it's a bug.

We don't want to copy-paste what you've done with cloning catalogs. And we don't want to have a password hanging somewhere plain in the connection.

Thank you.
Max.

BTW, if you want to really protect a password you should on XP and later systems have an option to hold password in protected memory only (provided by DPAPI) and pass protected byte array (by the scope SameProcess). That way it becomes much more tricky to get the password from stack.