There is no problem unless you use different versions of the sqlite library to open connections to the same db file at the same time. This is because different versions of the sqlite library may use different locking strategies. But if you just want to use a different version of sqlite with your own sqlite files in your app's sandbox, then that's just fine. You may need to do some symbol munging since the system's sqlite symbols will clash with your copy's symbols.
I was only considering the conflict between the system-provided SQLite and the private copy of SQLite in your binary, since that seemed to be what your article was about, and is the most common conflict. I hadn't actually considered that you would actually statically link two copies of the same version (or even different versions) of SQLite into your own binary and use those two different copies of SQLite to open connections to the same exact file.
In any case, don't have two different versions (by versions I mean copies) of SQLite open the same file in the same process. This is because os_unix.c does deferred closing of fds based on refcounting the number of open connections to the same path. With multiple libraries opening connections to the same path, the refcount for that path won't be correct in either copy of the library.
.... that's very different from what's stated in the article, and is actually what I'd expect to be the real problem. Dwelling on versions seems to be beside the point.
Sorry if the article is unclear. My intent was to clearly communicate that the problem can happen with any two instances, not necessarily of different versions. Like the nutshell summary at the top says.
But I also think that talking about different versions of SQLite is relevant, since dealing with those issues is one of the things that can lead an app developer toward the problem.
