See, for example, https://xtools.wmcloud.org/ec-rightschanges/en.wikipedia.org/Chew, compared to the enwiki rights log at https://en.wikipedia.org/wiki/Special:Log?type=rights&user=&page=User%3AChew&wpdate=&tagfilter=&wpfilters%5B%5D=newusers&wpFormIdentifier=logeventslist. Notice the template editor temporary addition does not appear in the xtools rights log, but does appear in the enwiki rights log with a revdelled edit summary.
XTools version: 3.20.3-dd4dc54f
The query's there. Made a test, on superset, from which we can see that the log_params for this log is actually NULL. So, essentially, we can't read what rights were changed, when the comment was redacted. After suspicions, I checked and log_params is also NULL'd when log_titlehas been deleted.
These rows are removed from the dataset there. The intention was (I believe) to remove logs where the action has been deleted, but we are also removing the logs where only the comment or the user or both removed. So we should use log_deleted to make an exception for when: a) the action itself was not redacted wholly (log_deleted % 2 == 0), b) we know what is deleted (log_deleted < 8), and c) something is redacted (log_deleted > 0). So that makes 2, 4, and 6.
The reasoning behind this is that I think it's better to have:
2001-01-01 | (inaccessible) | Username | (deleted)
or
2001-01-01 | (inaccessible) | (deleted) | blablabla
in XTools than no row (with a link from inaccessible to the log entry). Because without it it can be hard to account for what happens after.
(Interesting detail: this is quite a rare event. 6 occurences in the whole of enwp_p!)