Design of supported operations for properties

Hello Hydra

I would like to gather intel for all of you who don't follow neither GitHub nor HTTP APIs Slack.
Following a discussion on Slack [1], Angelo has raised a very interesting issue on GitHub [2] where we jointly conclude that the design of supported operations to be used on properties is unclear, and widely adopted wrong. Especially Karol seems to believe [3] that the spec indirectly suggests a usage different from what is widely deployed, including the issue tracker.
To the point, it seems that most, including myself, would serve an API Doc as follows (excerpt)
{
"supportedClass": {
"supportedProperty": {
"property": {
"@id": "schema:author",
"supportedOperation": { }
}
}
}
}

To rewrite this as a property path we'd get
?apiDocumentation supportedClass/supportedProperty/property/supportedOperation ?operation
The supportedOperation on rdf:Property seems wrong, and an intrusion on shared vocabularies. Instead we conclude that the design should be to place supported operations directly "under" hydra:SupportedProperty, just like is done with hydra:required etc. That would shorten that chain:
?apiDocumentation supportedClass/supportedProperty/supportedOperation ?operation
I wonder how many of you also object to the current "accepted" way and could give their feedback. I'm especially interested to hear back from Markus, given that the original demo is also structured in this way.
Best,
Tom

[1]: https://httpapis.slack.com/archives/C1JP575EX/p1558335863052600
[2]: https://github.com/HydraCG/Specifications/issues/196
[3]: https://github.com/HydraCG/Specifications/issues/196#issuecomment-494810749