I did some digging through the source code and found PhabricatorCalendarEvent::initializeNewCalendarEvent which does this:

if ($mode == 'public') {
  $view_policy = PhabricatorPolicies::getMostOpenPolicy();
}

basically it's
https://secure.phabricator.com/calendar/event/create/?mode=public
vs.
https://secure.phabricator.com/calendar/event/create/

I get the impression this was made before the form engines were a thing?

There's also mode=recurring... all these seem to do is change different default options on the form. Should I try to implement form edit engine support for this @epriestley? Would you be prepared to review it?

One problem with updating this is that recurring events currently work like this:

• When you view an instance of an event that hasn't been modified yet, we generate a fake request-only object.
• When you try to edit it, we turn it into a real event.

This means that when you view an event, it doesn't have a real ID or PHID yet, which makes several interactions sort of weird or buggy. For example, awarding a token to an instance of an event awards it to the parent event instead (and redirects you to the parent event).

All support infrastructure (tokens, subscribers, flags, EditEngine, etc) relies on objects having IDs/PHIDs. I poked at making EditEngine flexible enough to do the PHID/ID generation later, and sort of got it working, but I'm not happy with how it works and I don't think this is a reasonable pathway forward for tokens, subscribers, etc. I think I'm going to change it to work like this instead:

• When you view an instance of an event that hasn't been modified yet, we generate and store a stub object.
• This just has an ID/PHID and no other data.
• When you try to edit it, we turn it into a real event.

This is a small change conceptually, but unfortunately may not be all that small code-wise.