Q: Managed Masters unlinked after Photos Crash following extensive user input

I believe I have also caused this error by working with Faces for long periods of time (Naming faces, selecting "Not a Face" etc).  Rebuilding the Library does not relink the masters or identify them as recovered etc.  The masters are still in the Photos Package file if I browse it.  I've successfully recovered from this by reverting to a recent back up

It might be a bug in Photos. For the time being I'd keep frequent backups, so you can recover the library if it happens again and wait for the next release of Photos with macOS Sierra. Photos on Sierra is handling the naming of faces very different from the current version of Photos. It is expected to be released in fall, see: macOS Preview - Apple

Before you go to the trouble of recreating your library and losing your edits, try to find out, if something in your way of using Photos is problematic. Are you running out of storage on your system drive, or do you have plenty of free storage left? Is your Photos Library on a drive with a supported file system? If your library is on an external drive, it should be formatted MacOS Extended (Journaled) and directly connected, and not accessed across a network.

Leonie's suggestion that this may be a bug sounds accurate, and her advice on backups etc. is sound.

The problem you have found is similar to my experience with iPhoto a few years ago.  What worked for me then may provide a workaround for you now. 

My problem occurred with iPhoto maybe 9.2 or so, I do not remember the exact version.  There were two bugs which interacted to reveal one another. 

The first bug affected import.  When photos were imported the image file was copied onto your computer, for example into into the Masters folder.  Then various indices were updated to allow accessing the images from iPhoto.  Updating and writing the updated indexes to disk happened in the background, so the user never saw it.  The first bug was that the updated index was not written to disk until iPhoto Quit. 

The second bug affected Faces.  I do not know the details, I only know the result.  The bug was that if the set of known exemplars for a particular Face was too large, iPhoto would hang when trying to add additional Face examples.  Force-Quit was the only way to escape the hang. 

The Faces bug revealed the index write to disk bug.  I would import new photos from my camera.  Then I would verify faces suggested in the newly imported photos.  When I clicked Done, the Faces window would close and iPhoto would attempt to update its database.  That update process was VERY memory intensive.  For my daughter, I had about 2,500 Face examples.  When I added more examples, the iPhoto update ran for about 10 or 15 minutes, and Activity Monitor showed Memory Swap Used climbed to something like 30 or 40 GB !  Then the update process would complete, and Swap Memory Used would rapidly unwind down to zero.  For my wife, I had 3,500 Face examples, the update process would run for an hour or more, Swap Used would exceed 90 GB, then iPhoto would crash. 

Importing new photos, then crashing before Quitting iPhotos, revealed the import bug.  In this case, the photos had been imported into iPhoto, but the updated indexes had not been written to disk.  On crashing, the updated indexes were lost.  On relaunch, iPhoto used the old indexes which did not point to the recently imported photos.  The recently imported photos were in iPhoto's media, but iPhoto could not find them.  Rebuilding the iPhoto database allowed iPhoto to use the newly imported photos. 

Apple was not aware of what was happening, which unfortunately led to another error.  iPhotos Help recommended if photos which had been imported were not visible, connect your camera and re-import them.  This worked, provided that after importing you Quit before iPhotos crashed.  The problem was that the photos which had been imported earlier were also still in iPhotos media, even though not visible because the index which would have accessed them had been lost.  Then at some later time when the database was repaired or rebuilt, the lost imported photos would become indexed and visible.  Now photos imported both times would be visible, resulting in duplicates! 

Applying this experience to your situation leads to several insights. 

Large libraries can reveal issues which are not apparent with smaller libraries.  Sounds like you have a large library, which has stressed Photos to a breaking point.  You reached the breaking point last March.  Be aware of the size parameters you reached then: how many photos, how many named Faces, etc. 

Many simultaneous edits, such as deleting multiple blurry photos, or editing found Faces, also stresses Photos.  Each edit, each photo deleted, requires updating one of more indexes.  Photos does this in the background.  Photos and OS X are capable of carrying out many operations in parallel, and stacking others to wait until they can be done.  I do not know the details, but I do know nothing has infinite capacity.  Each edit requires updates, each update requires processing capacity and time.  There is always a limit of some kind somewhere, which will probably vary with system parameters such as processor speed, available RAM, disk access speed, etc. 

My guess is that the simple answer is the load you are imposing, with multiple deletions in rapid succession, etc., exceeds the capacity of your system to process the updates. 

Photos has multiple databases for various interrelated data sets such as images, face recognition information, locations, etc.  As Photo's databases increase in size, each update takes longer.  Taking longer means it is more likely that a previously entered edit is still being processed when you enter the next.  As unfinished processes accumulate, your system's processing speed slows even more.  As processing slows and you continue editing the load increases. Eventually some limit is exceeded and the application crashes.  On crashing, many processes are left incomplete.  On restart, many indices with parameters which were not written to disk, now point to nothing. 

It may help to observe Photos processes in Activity monitor.  Photos has things which run in the background, which become apparent as Photos or related processes taking cpu time.  This can be observed in Activity Monitor.  When I first launch Photos I see a high level of cpu use for several minutes.  Similarly I see high cpu use when photos are imported.  I suspect this is due to Photos modifying multiple indexes.  I suspect you will see the same.

The probably solution is to not overload your system.  That means impose the editing load at a rate the system can handle. 

When you launch Photos, also launch Activity Monitor.  Wait until Photos use of cpu slows to near zero before proceeding.  Then as you edit, continue watching Activity Monitor.  If Photos use of cpu seems excessive, stop editing.  When cpu use slows, resume.  To be on the safe side, Quit Photos every so often.  That should allow pending processes to complete, as well as ensure everything to that point is written to disk in case problems do develop. 

The rate at which you can edit without encountering a problem probably depends on the speed of your hardware, which determines how rapidly each edit task can be completed.  Adding RAM or a Solid State Disk might increase this speed.

There another way to look at this.  The ease of editing allows the processing capacity to be overwhelmed. 

Editing is too easy to use.  It's not a bug, it's a feature.  ;-)

In Photos I think I have seen problems, maybe a crash, when I edited Faces data.  My guess was that I was going too fast.  That was a while ago, but I believe I filed a report with Apple.  I think it would be helpful to Apple, and to all of us users, if you report your experience.  Apple needs to hear about processes that do not work, so they will become aware of the need to improve. 

http://www.apple.com/feedback/photos.html

"Some processes might only run after quitting" needs clarification, or perhaps amplification. 

What I meant to say was that it may be that some processes, such as writing data structures to disk, are completed after you select Quit before the app shuts down.  I suspect they are being written to disk constantly.  If the user edits slowly, the edits are written as they are made, with only a slight lag.  When your rate of editing exceeds the rate at which your system can write to disk, unwritten edits can accumulate and problems can arise.  You can test this, sort of.  Does Photos Quit rapidly if you have not been interacting with it for a while before you select Quit?  OTOH when you have been rapidly editing a lot, then Quit, how much of a lag is there before Photos goes away?  Does Activity Monitor help explain the lag (if you see one)?  If you run these tests, let us know what you find. 

On the other other hand, I suspect there may be some Photos processes, or rather System processes related to Photos, that do run after Quitting Photos.  What I am thinking of is searching the library for Faces.  I think, but am not sure, that I sometimes see new Face suggestions found for older photos, I think when Photos has not been running.  Or perhaps this happens as background processing while I have Photos open for other purposes, and I only occasionally notice the new suggestions. 

With so much of what Photos does hidden, the best we can do to figure things out is observe closely, then confirm one another's observations.