In fact, one of them is my primary Google calendar and the others are
all calendars to which I’m subscribed.

None of the .calendar directories contain any metadata; they just
contain an Events directory full of .ics files. The Info.plist
file in 38CFC480…7F.caldav is metadata about my primary Google
calendar, not the one I’m subscribed to.

If I go digging around, I eventually find:

5CE21AE9…FC.caldav/Info.plist

(At the top level, where 5CE21AE9…FC.caldav is a sibling to the 38CFC480…7F.caldav directory.)

That is the metadata for the calendar to which my event belongs. I
know this because I’ve looked at the event, I know what calendar it
should be in, and I know that the metadata in
5CE21AE9…FC.caldav/Info.plist is about that calendar (and there’s no
other calendar with that metadata).

There’s nothing else in 5CE21AE9…FC.caldav, just this metadata.

If I inspect the 5CE21AE9…FC.caldav/Info.plist, I find this key/value pair:

<key>Principal</key>
<string>38CFC480…7F</string>

So I can get from 5CE21AE9…FC.caldav to
38CFC480…7F.caldav,
but I cannot find anything that connects to the specific 952A7703…72.calendar.
(There’s nothing even vaguely useful in the actual .ics file, by the way.)

Does anyone have any idea how the MacOS calendar works out which of
the calendars in 38CFC480…7F.caldav contains the events that are to
be associated with 5CE21AE9…FC.caldav? Is it possible that
952A7703…72 is not a random string but is actually some kind of hash
of something?

Clues most humbly solicited.

P.S. Happy π day!

P.P.S. [About 90 minues later.] The answer is that it’s all mapped out
in ~/Library/Calendars/Calendar Cache which is an sqlite3
database. I still think I’ve probably written fewer SQL statements
than I have fingers, but I’ve now worked out one more: