Kirby stores its data in text files. The data requirements - such as each record needing an immutable, unique ID - are the same, regardless of the storage method. And the strategies for dealing with issues related to these features will also be the same. So, ask yourself: how would we handle this in a database?
In a database we’d have page records, related to other records - such as other pages, and/or image records and/or file records. In a database, we can specify what happens when we update and delete related records - in SQL you specify whether the operation cascades, updates or leaves the related pointer empty. In NoSQL the process is usually more manual, but the options are the same.
Copying is the same. In Kirby, if we ‘copy’ a page that has sub-pages, as well as files and images, we’ll copy those as well. In a database, this would be equal to creating new records - not only for the page, but also for the related pages, files and images. So, in a database we’d have to update the references in the new page to link to the newly copied sub-pages, files and images. In a NoSQL database, depending on how the records are structured, some of the sub-records might be embedded in the parent, and will be copied by default, while others might have to be manually re-linked.
The point is: these are all standard, data-handling issues, that have well-documented solutions, so it might end up posing less of a problem to the team than we might believe.