Thank you for your response and your clear and thorough explanations. Very helpful.
I can understand everything you have explained, but in mind I have an alternate understanding on one point you touched on, and that's the meaning of the $(request.auth.uid) part of the call.
So, I agree with you that the $(request.auth.uid) part of the call is to match the current-user, but I have recently understood that the call has a scope that is limited to the collection (or sub-collection, as the case may be) above it. For example, in Rachel's code, the collection/sub-collection above the $(request.auth.uid) call was 'users', and it was 'admins' and it was 'owner'. So, the check for the current-user's ID (to my understanding) would be limited to the relevant collection/sub-collection. Firstly, would this be accurate please?
The point on which my alternate understanding sits, is that the $(request.auth.uid) variable would not be the document-id of the document, or it needn't be, that, the call would check for a document within the relevant collection/sub-collection which features a field holding a field-value that is equal to the current user's UID. So, for example, if the 'users' collection of Rachel's code has documents in it, and a field of those documents is called 'authorID', and then in one of those documents the value of 'authorID' is that of the current user's ID, then that is the document that get() shall get, and it would be the value of the same document's 'passChallenge' field that must be 'true' for the allow-write condition. Please comment on the accuracy of this view.
If the $(request.auth.uid) part of the get(/databases/) call is only seeking a document with an ID that is equal to the ID of the current user, then, under what circumstances would Firestore produce a document with an ID that is equal to the current user's ID please?