Yes—darktable-cli can still touch Darktable database/config files, so lock conflicts are expected if Darktable is already running or if you launch multiple darktable-cli jobs in parallel.

Based on the shared solutions, you have two practical options:

1. Run only one instance at a time. If you start 4 parallel darktable-cli processes, they can collide on the lock files. Serializing the jobs or using a lock tool such as flock should avoid that.

2. Use an in-memory library and a unique config directory per job. The useful form is:

darktable-cli ... --core --library ':memory:' --configdir '/dev/shm/uniquejob'

This avoids the normal library DB and gives each export its own temporary config/database area, which helps when using sidecar XMP files.

So your --library syntax is conceptually valid, but using a normal file like /tmp/darktable.db may not be enough by itself because Darktable also uses files in the config directory. If this started with a newer version, it may also be a regression worth reporting upstream.