As for autofill memory limitations, this is largely an implementation detail: just process data stream in small chunks, that's it.
Unfortunately, KeePassium's data layer was designed in the times of iOS 11, before AutoFill became a thing. So I chose the easier path of loading and processing the whole file at once. This made sense for 10-20 MB databases on iPhones with 2 GB of RAM. By the time the mistake became obvious, it was much harder to switch to streamed processing, especially with a long queue of lower-hanging feature requests.
Nothing major, mostly UX improvements that could be defined as part of the new format. For instance, custom ordering of entry fields is not possible now because existing apps just sort them alphabetically on save. Multi-URL storage is basically KP2A's workaround adopted as-is by other apps.
That said, most of the concerns raised by the article — outdated schema, inefficiencies, governance issues — call for a new iteration of database format, but not necessarily SQLite. However, we would still be debating how to represent entry templates and how to accommodate features that stretch format's initial assumptions (be it multi-URLs or smart groups). We may still discover that passkeys need more fields than initially foreseen. Then someone would come up with item-level access rights scheme. Then something else.
All of these are already possible with XML+Gzip, just as much as with SQLite/SQLCipher. The main advantage of the latter is the standard, multi-platform library with a permissive license, instead of KDBX' specialized parsing. Switching to SQLite would probably lower the entry barrier for new apps. Which would be a good thing on the surface (more choice), but could end up with the same devil-in-details bedlam as the status quo.
Breaking format changes is not such a major issue, they happened before: kdb → pre-2.08 kdbx → kdbx3 → kdbx4. If the new format is worth it, popular apps will adopt it within a few years — while still supporting older formats. Users would just stick with their current format until the ecosystem catches up, as it happened with KDBX and KDBX4.
Yes, you got it right. The source code is published under the GPL, but App Store ToS impose additional restrictions that are incompatible with the GPL. So we have to dual-license the project, and only the copyright owner can do that. In order to maintain that role, we can only accept contributions with a CLA (two pages of legalese that transfer the copyright). This is obviously a deterrent for contributions: over the 5 years, I believe there were only 3 people who signed it :)
We are undergoing the same CASA audit (required to access Google Drive API). And we do have people forking and building the project from source, so one can hope they read what they compile. Strongbox' source code is half-closed (see #784 in their repo) so source-level independent audit is impossible.
Otherwise, no. A third-party audit costs like a year of part-time developer, and at this stage the developer is more useful.
Unfortunately, KeePassium's data layer was designed in the times of iOS 11, before AutoFill became a thing. So I chose the easier path of loading and processing the whole file at once. This made sense for 10-20 MB databases on iPhones with 2 GB of RAM. By the time the mistake became obvious, it was much harder to switch to streamed processing, especially with a long queue of lower-hanging feature requests.