So I investigated this and found the reason, it's related to flow of current message system in connection with reverting:

• When user hit revert and warn, 2 async jobs are created, one for revert and one for message with revert as related edit
• Both actions are processed in parallel, reverting naturally takes couple of API calls, so does the messaging
• Due to current implementation talk page is in-memory edited first and then it waits for revert to finish, then it's actually written
• Later talk page is overwritten, restoring the revert

Current message flow is:

• Send()
• PreflightCheck()
• Download the current talk page
• Modify the talk page in memory
• Wait for related edit to finish
• Write the talk page

Potentially fixed flow is:

• Send()
• Wait for related edit to finish (maybe as part of preflight?)
• PreflightCheck()
• Download the current talk page
• Modify the talk page in memory
• Write the talk page

Before changing the flow I have to think if this has potential to break anything.

Note to self: current check for related edit is around line 80 here:

bool Message::IsFinished()
{
    if (this->Done())
    {
        return true;
    }
    if (this->Dependency != nullptr)
    {
        if (!this->Dependency->IsProcessed())
        {

That would need to be moved somewhere else

Another note to self: why the hell isn't the mechanism that checks if talk page wasn't edited meanwhile (since last text retrieval) preventing this from happening? BaseTimestamp vs StartTimestamp should prevent this.