The “one account approved, rest denied” thing makes sense from the point of view that 1 application should be registered for “a single purpose”: Policy clarification - multiple applications for the same use case
The new developer dashboard can now manage old apps (ones you previously registered on apps.twitter.com) https://developer.twitter.com/en/apps so it shouldn’t be a problem.
For 3. This is generally how it could work:
Lets say @TAMUCMAdmin is a twitter account you operate, and is an approved developer account. You then either register a new app called “Alert System”, or use an existing one that works, and use the Consumer Key & Secret of the app to “authenticate” each of your campus accounts, eg: @Campus1Alerts, @Campus2Alerts, @Campus3Alerts @CampusAlertsDevTesting etc…
You can use something like https://github.com/twitter/twurl to do the OAuth thing manually once for each account, the tokens are long lived and won’t expire unless you reset them. (It does it this way if i remember correctly: https://developer.twitter.com/en/docs/basics/authentication/overview/pin-based-oauth )
Now to tweet alerts for separate campuses, each account now has the same Consumer Key & secret, but their own unique Access Token & Secret. Everything else in your system should be exactly as before - except now you only use 1 main application key instead of separate ones for each campus.
Also, it doesn’t really matter which account owns the app, what matters is the combination of Consumer key & secret and Access token & secret - so @Campus1Alerts could be the actual Application “owner” but the other accounts will still have their own access tokens and tweet separately just fine.
Hope that helps!