Simply because you know a way to solve such a scenario, doesn't mean that is enough. By which, I only mean to point out that this IS a consistency request, and not a "broke, so fix it".

Need I quote the help file?:
Code:
on 1:CLOSE:@:/echo -s Just closed $target custom window


That line has been there for years.

That event is going to be triggered when $target is closed.

The only difference between /close and that X is the involvement of GUI activity. The [X] is, effectively, calling an internal variety of /close... I wouldn't even be surprised if its roughly the same chunk of code.

I know a current scripted sollution to this. One does something like (off my head-top):

Code:
alias window.close {
  if ($window(@window)) { close -@ @window }
  unset %window.*
}
on *:close:@window: {
  window.close
}


And it's done.

I'd be interested to know what very good reasons you reference for NOT having ON CLOSE do what its name clearly suggests it does, though. I see not one good reason that /close should be named /close and not trigger the ON CLOSE event.

Script interpreters change all the time, and I see this change being not only minor (to function), but logical.

An -x exception switch would also be logical.