Hi Terence and Leonie,
You can run several Aperture on the same computer as long as all Aperture are using distinct libraries.
What Aperture does is to create a simple lock file in <your Aperture library>.aplibrary/Database/apdb The lock file contains the PID of the process. So not two Aperture could open the same library (although I don't know how good they have manage the concurrent creation, locking, verification of this lock, this is a typical and difficult software engineering problem)
Anyway, I have not said that Aperture supports concurrent editing. That a file is a database or a simple text file, you have basically the same issues on network or in concurrent environment. So if the folder structure holds simple, flat text file or xml object or databases, it is still a bunch of files (this is a UNIX system by the way 😉 ).
Aperture contains more than one SQLlite file, there are some at the root folder, some under Database/apdb etc. there are also XML files that could be used as database.
Anyhow, editing a file (SQLlite, XML, txt, doc, etc.) either on a share or locally is plain similar. The drive can fail too, although much less likely than the network.
Network file edition can have a few shortcomings, but nothing that when known can be blocking.
Locking files over the network can however be tricky and depends largely on the network protocol used (NFS, SMB/CIFS or AFP just to name a few). In addition, if you import files from /Users/foo/Photos in Aperture (without copying them within Aperture), they might not be visible from another computer or only the previews, as the path /Users/foo/Photos is not "visible" from the other computer.
What really is a problem when you put a file not locally is the file system type and its features. HFS+ supports extended attributes (metadata), many other file systems support these but the API (how the software, such as Aperture, access this feature) might not be similar, in addition the amount of metadata or their structure might differ from file system to another. And this is where you might lose information.
A tool like Dropbox is pretty good at maintaining the metadata across different computers, and it has been adapted to do so for OS X specifically (and also for Linux and Windows).
The second problem is if you would have a Mac and share via SMB (the Windows share network protocol, aka CIFS on recent Windows versions) the library, SMB might not support the reading and writing of HFS+ metadata, thus data loss might occur.
Apple is just warning us of all these shortcomings, and advise to use local storage formatted as HFS+. Because even a local external disk formatted as NTFS or other file system could be a problem.
However, power users who understand the risks and limitations of a network share (in general) can create a disk image on a share (even if it is SMB). As for OS X, once the disk image is mounted, it is just like any other local hard disk, it is just "slower" especially latency wise. OS X supports perfectly disk image mounted on a share, it takes care of properly synchronising it.
Of course, due to the nature of the link between the application data and where they are stored, in case of application or OS crash, the amount of data loss could be greater than when the data are held locally.
I hope this clarify better my post.
Note: another shortcoming of having it on the network is: Aperture lock the library by creating a file with a process ID. If the same library is opened from another computer on the network, this other Aperture instance might see the lock file and could perhaps not find the corresponding running process. This Aperture instance might then decide to ignore the lock and proceed with opening the library. This might have some consequences.
But I haven't developed Aperture so I don't know how it would behave 🙂