XDCC as such is a custom function written and supported by a client script. There's no rule or expectation how different implementations may behave. mIRC doesn't even have built-in support for services such as nickserv and chanserv which are used by almost every network.
Aside from that side of the argument, it also can't support it in full confidence. As pball explained, mIRC would need to parse every message you send and then hope that the next transfer was for that pack. That's not necessarily going to be the case. Can't packs be queued and split into multiple transfers? Now not only does mIRC have to parse your messages, it needs to maintain a list of them and then match up the file names you receive to the packs you requested. I don't think that's possible for even you to do without also parsing and storing the file list you were given.
well, assuming the next package downloaded has the corresponding pack number of the last "/msg nickname xdcc send #N" is obviously not a reliable way to do this, since, as said, packages can be queued. but, if this info is simply combined with nickname of the sender, it becomes sure that the next package received from that user will have that pack number.
btw since this feature request is receiving so many objections it's probably better to abandon the idea and just write it as a remote script.
thanks anyway
