It looks like I've not clarified the actual requested program change in my initial post.

I'd like to ask that this FT8 protocol limitation will be embedded in the WSJT-X "Auto Seq" code.

Since there is no way for two stations with a special/long callsign to complete a QSO, the program should ignore such an incoming CQ response from a special/long callsign when the local callsign is special/long. I've seen it ignoring special/long callsigns in another scenario (which I cannot remember now).

Perhaps all messages from special/long callsign to another special/long callsign should be ignored by the "Auto Seq" code.

Perhaps even more - WSJT-X would avoid sending any messages from special/long callsign to another special/long callsign and provide a short message explaining why.

Zeev 4X5ZS

Somebody called you with a special callsign too.  Can't have two of them.  That's what the <....> is indicating. Anytime you see <...> means you have not ever decoded a plain message from the "unknown" callsign.You'll see in your messages TX 1 and TX 5 will both have your callsign without <> which means that is a "plain" message.  When your callsign is in <> means it is hashed in order to fit in the limited message length.Would be nice to have some message in the decode window explaining it though.
Mike W9MDB

Hello,

I've been calling CQ with a Special callsign and the "Calling CQ forces Call 1st" was set as usual. At some point, I received a response from an unknown callsign.

As a result, "Enable TX" was turned-off, "Next T2" was enabled and there was no T2 message to transmit

See screenshot at https://user-images.githubusercontent.com/1304610/180768878-3263b31e-91a3-4db7-b706-daa80e1e400a.png

This repeated itself after every time I clicked "Enable TX".
The only workaround I could find is to turn-off the "Calling CQ forces Call 1st" settings.

It is strange that WSJT-X decided to initiate a response to the CQ while the program would be unable to respond to it.

Is there something else I could do?

73 de 4X5ZS