Without saying anything about OSX in particular, any operating system that requires network access to log in is a user-hostile piece of shit, and the linked bug#284 pretty well implies that that is in fact the case. It's entirely possible that the problem is due to incompatibities with new OS code or bugs in the firewall program (edit: ie, your case a and case b), but evidence in the bug report pretty clearly suggests that the firewall is correctly blocking all non-whitelisted network requests, and the failure to log in is due to the OS maliciously trying to phone home against the user's wishes.

You're making a mistake jumping to the assumption of malice rather than thinking about all of the other possibilities. This class of bugs is pretty common: people sometimes test software without a network connection at all but its far less common to test with one which drops packets but does not return errors. I've had to fix variations of this problem on Windows, Linux, and things like VMware's HA module.

My guess would be that it's something like checking for things like application revocation or other updates or, if you have iCloud enabled, something like attempting to synchronize your settings or data.

No, I'm concluding either malice or incompetence-to-the point-of-being-indistinguishable-from-malice, based on the premise that login (to the local computer, when the end user has not explicitly configured it to) involves any network interaction at all. It might not be true that OSX login involves network IO (as I more or less admitted above, I haven't checked), but that was not a assumption I jumped to.

>its far less common to test with one which drops packets but does not return errors.

That sounds pretty common to me.

That hasn’t been true in my experience using software from Microsoft, Google, Apple, Signal, etc. It seems like most projects only get serious about that after user outcry unless they’re staffed by very experienced engineers.