Field event.type should not be reserved

I found event.type, event.category, ... are planned for some canonical categorization with permitted set of values.
From my perspective I do not think it is really possible and could make things very unclear. From our logs I see many sources where event.type, event.category is appropriate to use but sometimes contains very different values.
We already use event.type, event.category, ... with our org prefix because it fits to the use case. We also defined another field to help us with categorization.

For example we have system which generates multiple feed types, each feed type has logs of multiple categories and types and kinds. Such as:
- feed.category: tunnellogs
- event.kind: EVENT
- event.type: AUDIT
- event.category: TUNNEL_EVENT (can not share the field with feed.category as each defines the different thing and can be different)
- event.action: DOWN
- event.reason: timeout

This is perfectly clear and easy to understand during search. Also very usable for different event soruces.
You can see TUNNEL_EVENT category of events perfectly fits to event.category but I really do not thing it would be in ECS the permitted list values for this field. For example for exchange tracking the event.type can be NOTIFYMAPI ...

I think the effort for defining permitted values .... is great but there are a lot of use cases where it is impossible. So maybe all the event fields should be allowed to use (just document how without permitted values list) and something like "event.canonical" with multiple subfields would be great to introduce.