I have some ideas about improvement of RETURNING:

1. Allow old, new, and excluded. (If a INSERT statement has a upsert clause, then all three are meaningful, I think. If there is no conflict, then the old values will all be null, I think. I would also think that possibly also for REPLACE, too, but in the case of REPLACE, the new values will be the same as the excluded values, as far as I can tell.)

2. Allow RETURNING on DELETE and UPDATE of virtual tables. The code might need to be changed to use a index that can read all columns that you want to returning, if a RETURNING clause is used on DELETE. For UPDATE, I would think that it will need to avoid making sqlite3_vtab_nochange true, so that it can ensure that the implementation will return the proper value for that column.

3. Allow RETURNING in CTE (including in triggers). Probably it is sensible to prohibit the use of NOT MATERIALIZED in statements that include a RETURNING in a CTE (since it will have to be materialized in order to work).

4. Allow non-window aggregate functions, so that you can write RETURNING COUNT() as an alternative of PRAGMA count_changes. (It is not really needed if RETURNING in CTE is possible, but may still be useful.)

5. It might be useful for a INSERT statement to be able to return the original data without updating it if a conflict is found, although I am unsure what syntax would be, or how useful it is to other people, though.