Hello, thanks for the reply, and thanks even more for your Event Taps Testbench application! I use it frequently throughout my work and find it to be extremely useful.
I can help clarify the difference between "Accessibility" and "Automation" at least a bit. Accessibility is the permission an application needs to use Apple's Accessibility API in addition to posting events, and monitoring and filtering them with event taps. I think it's something of a misnomer now that event taps and event posting is mixed in with it, as neither of those APIs are actually part of Accessibility, though I imagine many accessibility applications make use of them. Apple's Accessibility API is documented here: https://developer.apple.com/documentation/applicationservices/axuielement_h
"Automation" is what's required for an application to be able to send Apple Events to another application. This is typically done with applets and scripts created using Script Editor but is of course also possible using various other APIs. Every time an application sends an apple event to an app it hasn't previously tried to automate before, it will trigger a new permissions modal dialog asking the user to approve that. Consequently, the "Automation" list in the Security & Privacy system preferences will list each application that has tried to send an apple event, and then nested under them will be each application that it tried to send the apple event to, with a check box for granting or revoking permission. And since AppleScript provides its own interface for using Accessibility features, it creates the rather unfortunate situation where some AppleScripts might need both the Automation and Accessibility permission in order to function. And "full disk access". And a slew of other permissions.
It's really quite a mess, especially given that this triggers numerous nagging modal dialogs. Most users will see those and find them to be frequent and irritating enough that they'll care more about getting rid of them than reading what they have to say, and consequently will click the approve button without considering what they're doing. It's Windows Vista's failed security model all over again. I'm not sure why the engineers at Apple thought this was a good idea.
Soapboxing aside, though, I'm still not sure what "Input Monitoring" is for. In at least one previous beta of 10.15, and I'm not sure which one (probably beta 4 or 5?), my app triggered a modal dialog requesting "input monitoring" permission when it attempted to create an event tap that listened for keystrokes, I think. I'm not 100% sure of that because I can't trigger it again. As you noted, in beta 7 and now in beta 8 creating keyboard event taps does not trigger a modal dialog asking for permission any longer.
I wish someone from Apple would step in and clear this up. It's very important for apps that must observe and filter keystrokes, and I worry that a future release of macOS, possibly even a bugfix update, will suddenly impose this security restriction again without warning, breaking our apps and annoying our users. Historically Apple has not been properly communicative about when these restrictions will be imposed, and how one is supposed to deal with them.
