Probably, the person writing that piece actually got official notification that the termination would occur on September 30 or the end of September, and miswrote, though that kind of error in an official notice is not unheard of.

This is fine for an end date. Any duration should be specified as half-open, t₀ <= t < t₁. This way it's clear that September, even its last day, is in the period and October is not.

Yes, but try codifying that and you won’t get far enough to make that comparison. E.g. mentally or on a computer, ‘Date.Parse(“2019-09-31”)’ is an error ;)

Any properly defined software should take a date that doesn't exist and move it forward or backward to a date that does. Leap years would crash every computer every February if that wasn't taken into account.

Except that the whole February/leap year case is part of the Gregorian calendar. Moving the date forward or backward to a date that does exist is not a set rule and would only cause unnecessary confusion for a user or other developer for that matter; even worse if you were to do it without notifying the user. Wouldn't you agree that it'd just be better to catch the error and tell the user they "done messed up"?

Right, that's totally how people will reason about a date that doesn't exist. This is why the other side of the business can't stand talking to some of us.