It is pretty much by definition, we are requiring to introduce an API change to meet the ask, which means the next "compat breaking release" = 7.1.
If we want evaluate anything sooner, we can consider enhancing the existing system user logs which are accessible through REST and already contains some of the requested events. Adding new events will involve dependencies on other services/facilities. Some of these events are already conditionally reported by audit. Audit is not enabled by default and user needs to opt-in to get these events, but the at least the places in the code to triggered such events are already identified.
We can consider leveraging the audit facility to also report system events to accommodate missing events. As to the parse-friendly requirement, we can post-append to the end of the message a 'hints' that comply to some parsable format (json/yaml) so that automation logic can take advantage of it. When operating in a mixed mode cluster, the UI can hide this extra content for nodes which are already upgraded, but that does leave older release nodes that will show the full string which may be a bit ugly, but than again, that's the cost of introducing this capability without breaking compatibility. At least some parties (cloud/customers) will be able to take advantage of this sooner, as oppose to waiting for next compat release (7.1).
In 7.1 release, we can move the 'hint' portion to a first class new fields we can introduce in the user log APIs.
The notion of the 'feed' which suggest some sort of a continuous delivery of events - we can introduce a streaming API, but again that's a bigger change and API compat. We can introduce an additional query args to specify timestamp from which events should be returned. Client will need to manage minimal state to remember their last query. This is more of an efficiency consideration.
As we will be adding more events, but still assuming they are pretty high level and non-frequent, it is possible the log will grow in size. We are currently holding 3K entries as part of the config, which is persisted and replicated. We need to eval whether we can increase this cap, but with full awareness that we cannot carry a major memory cost. Again, we are making the assumption that once a client retrieves and process the info, it should be ok for entries to get lost if log gets rotated.