Gängige Datenbanksysteme, in DotNet allen voran MSSQL, alternativ die altbewährten : MySQL, PostgreSQL, SQLite, MariaDB; oder eines der neueren NoSQL-Systeme wie CouchDB oder MongoDB, wobei ich mir hier nur bei CouchDB sicher bin, dass es .net-Wrapper gibt.

Die Flatfile-Lösungen (SQLite, und jegliche NoSQL-Systeme) fallen bei Mehrinstanznutzung ebenfalls raus, da Änderungen nicht sofort übernommen werden können.
Hier die Information zu SQLite.
Somit bist du gezwungen einen vollständigen Server (MSSQL, MySQL, MariaDB, o.Ä.) zu nutzen. Sei dir aber im Klaren, dass du dir das Entity Framework anschauen solltest. (funktioniert mit MSSQL, MySQL, MariaDB, SQLite)

das DataSet fällt damit schon einmal weg.

Das scheint mir total falsch.
Vom Dataset fällt überhaupt nichts weg, sondern es kommt nur eine annere Weise der Befüllung hinzu - abgestimmt auf die Bedürfnisse deiner MehrBenutzer-Anwendung.
Wie diese Abstimmung aussieht ist individuell verschieden, das geht von ganz einfach bis super-anspruchsvoll.

Ja, das ist in der Datenbänkerei als das "Concurrency"-Problem bekannt, entsprechend konfigurierte DataAdapter werfen sogar eine Exception, die so heisst.
Wie gesagt: zur "anneren Art der Befüllung" muss individuell konzipiert werden. Du musst dir die Strategie überlegen - man könnte folgendes machen:
1) last-in-wins: der letzte Schreiber überschreibt den anneren
2) first-in-wins: der letzte Schreiber wird abgelehnt
3) lock-on-edit: der erste Schreiber blockiert den Datensatz, sodass der 2. Schreiber von vornherein sieht, dass dieser Datensatz in Bearbeitung und readonly ist

Und fürs lock-on-edit gibts alle möglichen Varianten, mit Vor-und Nach-teilen.
Gängig ist glaub, einen Timestamp zu setzen, wenn man einen Datensatz editieren will.
Und auch hier die Frage, wann den Timestamp setzen: Gleich die ganze Tabelle sperren, wenn du sie abrufst?
Und das mit dem Sperren ist heikel, denn Vorsorge muss getroffen sein, dass wenn einer einen DS sperrt, und dann garkeine Änderung tätigt - die Sperre muss ja mit einem TimeOut versehen sein.

4) Königsweg ist natürlich, wenn möglich ist, die Rechte so zu legen, dass jeder User nur seine eigenen Datensätze zu Gesicht bekommt. Dann tritt Concurrency ja auch in Mehrbenutzer-Systemen garnicht auf.

Aber wie gesagt: Das ist nun echt Datenbank-Programmierung - das Dataset brauchst du weiterhin, nur wie es befüllt wird verkompliziert sich u.U. enorm.

natürlich.
Das ist ja ein logisches und unvermeidbares Problem. Es kann keine Datenbank geben, die dieses Problem nicht hat.
Auch wenn 2 Anwendungen dieselbe Dataset-Datei einlesen und bearbeiten besteht das Problem, oder auch wenn du dasselbe Word-Dokument zwei mal öffnest.

Man kann sogar sagen: Word folgt der "lock-on-edit" - Strategie, während Notepad für seine Dokumente einfach "last-in-wins" anwendet.