I can create this behavior in several different ways. I'm going to think out loud here for a minute in case somebody has a suggestion.

Each way has advantages and disadvantages.

(1) The first way is what you originally suggested, i.e., let the user define numpad2 as a modifier. My initial objection was wrong because keys get disabled every time they get assigned as unmodified hotkeys. This is no worse. The only thing that's different about this is that the result may be unexpected. This can be handled by making the syntax very explicit so the user gets a warning simply by writing the hotkey file. E.g., something like <TreatKeyAsModifier numpad2>.

Advantage over other methods: easy for me to implement.
Disadvantage: you (Basilikos) will have to define a huge number of hotkeys -- one for every possible combination of numpad keys and Nostromo keys.

(2) Transient state variables. Don't get alarmed, these state variables only exist while you hold down the numpad key. When you release the key, they destroy themselves. So there's no permanent state. This idea requrires either (a) implicit exposure of the variables to the user in the hotkey file or (b) explicit exposure or (c) if-conditions in the hotkey file.

(2a) Implicit variables. For example, the user defines <hotkey numpad2> with new command <SetDefaultDestination 192.168.1.101 WOW1>. Also defines <hotkeyUP numpad 2> with new command <ClearDefaultDestination>. This <HotkeyUP> definition handles your objection about permanent state. Then the user defines Nostromo hotkeys without SendPC and without SendWin.

advantage: it would be pretty easy to design < SetDefaultDestination> so it takes not just one destination as its argument but a list. Then the Nostromo hotkey could broadcast the command to the whole list. There's your broadcast.

disadvantage: without the list, same disadvantage as (1).

(2b) Explicit variables. For example user defines <Hotkey numpad2> with <DefineVariable $TargetWindow = WoW1>. Defines <hotkeyUP numpad2> with <ReleaseVariable $TargetWindow>. (That answers your objection about permanent state.) Defines Nostromo hotkey with <SendWin $TargetWindow>

disadvantage: Very geeky. This is over the heads of most users.
advantage: same as (2a) but probably more powerful as a long term part of the program that will get used elsewhere.

(2c) If-conditions. The user wouldn't define anything for numpad2. Just a hotkey for each Nostromo definition. Something like:

<hotkey Alt Ctrl 7>
<if numpad2 is pressed>
<SendPC 192.168.1.101>
<else>
<SendPC 192.168.1.102>
etc.

disadvantage: might be a lot of work for me to implement. I don't feel like writing a real interpreter for this program. Probably less work for the user than (1) but more work than (2a) or (2c) assuming I implement the lists.

advantage: it's geeky but probably easier for people to use than the explicit variables.