> it's probably more about developer time, maintenance burden, etc. That's a large part of it, yes. The sqlite project has only 2 full-time core developers and

> it's probably more about developer time, maintenance burden, etc. That's a large part of it, yes. The sqlite project has only 2 full-time core developers and, AFAIK, only 3 current part-timers who tend to work on more "outer rim" features like the shell app, the .Net bindings, and the new WASM/JS parts. Richard (sqlite architect/lead) has an explicit goal of supporting sqlite through at least 2050, and sqlite has a long history of strong backwards compatibility guarantees. Every feature (e.g. new SQL-facing function) added to it may well have to be maintained until 2050 by that small group of people. Thus Richard is necessarily extremely selective about what goes in.