Ya, el ejemplo que he puesto es bastante tonto.

Duplicado de registros es que te rechazen la bd data repetida o rechazo de campos de valor exclusivo (unico).

Las versiones no se graban al mismo tiempo como dices, sino que "version" es una copia de una transaccion (basicamente) con un numero de serie o mecanismo similar. Eso es viejo y precede a la tecnica multigeneracion: Se graba la transaccion y se hace una copia de respaldo para roll back. Eso tambien lo hace SQLite3.

Los sistemas de tipo servidor que llaman multigeneracionales se apoyan en el mismo principio de la copia para rollback y esas copias no constituyen de ninguna manera el que "varios usuarios escriban en la misma tabla al mismo tiempo", cada grabacion de cada usuario graba la transaccion y la copia, uno por uno, a su vez.

De hecho, el sistema multigeneracion limita aun mas los escritos finales a las tablas, pues segun el caso, se pueden considerar grabaciones temporales, y separadas de la verdadera tabla.

SQLite hace algo similar, pero a nivel limitado, aun en su manera de-fault de controlar los locks, usando archivos temporales en memoria o en disco, con su Pager Module.

Y de hecho, permite aumentar ese control si se desea, pues tiene un modo (que no es default y se configura) que aun no se ha discutido aqui, que se llama "shared cache" y "shadow-paging".

Aqui les pongo enlace a la documentacion oficial del asunto:
SQLite Shared-Cache Mode:
http://www.sqlite.org/sharedcache.html


Y este otro link (tambien documentacion oficial de SQLite3) titulado File Locking and Concurrency Control (Control de Concurrencia):
http://www.sqlite.org/lockingv3.html

Igual pasa con SQlite3, dos usuarios pueden grabar a la misma tabla con diferencia de tiempo de milisegundos.

Los limitaciones de SQlite3 para uso multisuario no han sido nunca en ese sentido.