We have to be mindful, but not afraid of evolving the #ActivityPub standard regularly. Already now Mastodon (and other implementations) is "abusing" the subject field to implement CW. Implementing RT/QT without it being reflected in the standard only adds more distance to other implementations of ActivityPub. But also - the ActivityPub WG hasn't been really active on adapting the standard to real world use lately, IMHO. So. Work to do!
For many, many years I have tried to convince SSOs (Standard Setting Organisations) that there is a problem with Open Standards, when they do not offer at least three things maintained in parallel:
1. The Open Standard
2. An #OpenSource reference implementation
3. An Open Source and publicly available validator to check compliance
A lot of the problems with Open Standards (unclear interpretations leading to non-interoperable implementations) could be avoided by having all 3 things available.
The weird thing is - if you turn the whole concept of software standards upside down, it works actually far better and faster:
1. Write code (in the open, cooperatively)
2. Derive stable API from code
3. Translate API description/documentation to standard language
Using existing code to create/define a standard can be almost completely automated and delivers all three parts (standard, reference implementation, validator) more or less as a byproduct ;)