You could always overload your /debug and generalize it, for instance:

Code:
alias debug { 
  if (-i nul debug_multiplex != $1-) {
    echo $color(info) -sl * /debug: do not use this command, handle the DEBUG signal event instead.
  }
  !debug $1-
}
alias debug_multiplex { .signal -n DEBUG $1- | return $1- }
ON *:CONNECT:.debug -i nul debug_multiplex

; Uncomment this for the standard /debug @debug behaviour.
;ON *:SIGNAL:DEBUG:window @debug | echo @debug $1-


Instead of the error, you could also intelligently wrap the new command within the SIGNAL events, allowing you to handle multiple /debug commands at a time. It wouldn't be very hard. You'd add the file/window argument to a list of outputs and just loop through those outputs in your signal event:

Code:
; inside /debug alias:
var %opts = ""
if (-* iswm $1) { %opts = $1 | tokenize 32 $2- }
if ($1 == off) {
  %debug_outputs = $remtok(%debug_outputs,$2,0,32)
}
else {
  if (i isin %opts) { echo $color(info) -sl * /debug: handle the DEBUG signal event instead. | return }
  var %output = $iif($1 == on,debug.log,$1)
  if (@* iswm %output) window $iif(n isin %opts,-n,) %output
  %debug_outputs = $addtok(%debug_outputs,%output,32)
}

; add a default signal event
on *:SIGNAL:DEBUG: {
  var %i = 1
  while ($gettok(%debug_outputs,%i,32)) {
    var %output = $v1
    $iif(@* iswm %output,echo,write) %output $1-
    inc %i
  }
}


This doesn't handle some of the optional debug switches, but it should be clear how to add support for those, and not very difficult. I show the error message if -i is used, suggesting that they use the signal event instead of a custom alias. Wouldn't be that hard to support the identifier argument too, though.