Your current sentence is:
"to have improved presentation of real-time text during message correction"
I understand now that there may be real-time display during last message correction. And that full support causes improved presentation. So you may keep the sentence.
I am a bit afraid that all the cases you describe of mixed support or not for XEP-0301 and XEP-0308, and transmitting features with or without completed negotiation contain a lot of risks for unexpected behavior.
Will it for example be possible to return to appending text in a normal way at the end of the current message after you have completed editing corrections if your receiver does not understand the rtt id attribute but receive them and act on them. Do you have any rules for how to leave the current message, and how to return to it? Will the received messages with <body/> really erase the right part of the real-time delivered text?
Would it not be safer to say that you must support receiving id= and reacting properly if you declare support of both XEP-0301 and XEP-0308, and that you shall not send id attributes if negotiation for support of both XEP-0308 and XEP-0301 fail?
Gunnar
