I don't think we should do this:

• We show disabled users' stuff everywhere else by default.
• When we don't do this, users are occasionally confused by it, because the rule isn't obvious.
• It's hard for me to figure out that this is the problem when supporting these questions (there are a million reasons the stuff could not be there).
• Users have a rare but real interest in showing disabled users' stuff, so we'd need to provide some way to see it.
• Generally, this is the same issue as not showing disabled users in typeaheads. It used to cause user confusion, come up fairly often, and be a big pain to debug. Since we started showing the results with "Disabled User" on exact matches I haven't seen any reports, and haven't had to adjust any UIs to provide a way to query disabled users.

What's the specific view/use case that this makes messy? I'd rather frame this as providing better ways to get the results you care about -- presumably you don't want events of most users on whatever you're looking at, they just don't happen to have events?

To put it another way: if we hid these events, but most users had several events every week, would the UI you're looking at be useful? I think that's the primary case we should be looking at.

True, if I could just bundle "Phacility High Command" into my default view, that saves the case. I'm just thinking at the corp level when someone leaves a company, things like their meeting schedule should just turn off.

(I could assume though, that you should just punt user x out of whatever project they are in if disabled)

My tentative plan here is to make the filter on /calendar/event/ have an option like:

View as: [Calendar V]
         [List      ]

...and basically merge it into /calendar/, so you can run/save any query and choose how you want the results to look. It will require a little bit of tweaking since the paging needs to become month-based, but shouldn't be too bad.

No specific hurry, for sure. You know what I want more than I usually do. :)