window processIds consistent with Node child_process subprocess pids

[NNskelly]

Is your feature request related to a problem? Please describe.
My primary use case for a library like node-window-manager is when I'm making a node app to manage the execution of other apps. When I use e.g. child_process.spawn() to launch an app, I get back a process handle with a process ID. Other libraries like npm node-process-windows have a pid scheme that matches the child_process pids, so I can usually find the window of the process I just launched and attempt to manipulate it (although node-process-windows appears unable to reliably e.g. bring a window to foreground). node-window-manager finds a lot of windows, but neither the window.id nor the window.processId match the child_process pids, so I can at best compare the window paths to whatever path I launched my subprocess at, but that gets sloppy and unreliable, especially when the target path had any degree of indirection (e.g. a relative path, .lnk shortcut, etc.).

Describe the solution you'd like
Ideally, window.processId is the actual process ID, consistent between all contexts that utilize processes and process IDs. Alternatively, if window.processId is already its own thing with its own expectations elsewhere, window should have some other property or getter returning a value consistent with subprocess.pid.

Describe alternatives you've considered
As mentioned, at least one competing library already does this- node-process-windows- it simply uses a helper tool that is not capable of certain manipulations on more current Windows builds. And while it's technically possible to compare process launch paths with window paths, discrepancies can arise which make path comparison only really useful for human-review sanity-checking or isolating which window ought-probably to have the pid I'm looking for.

Additional context

[NNskelly]

Update:
It looks like part but not all of this is my own setup. There are some apps, like popular web browsers, which spawn a million "windows" none of which are the original process handle, and I can't reasonably expect node-window-manager to isolate a window by process id under those circumstances. Sometimes node-process-windows even fails in this case.
However, there are some cases where something window-y enough for node-process-windows to find does exist, and when given, like, a full 5-second setTimeout delay, node-window-manager can eventually include it, with the expected processId, in windowManager.getWindows(), and from there, successfully bring it to top. (sometimes several other windows or window-y objects related to the same application are found immediately, with other processIds, hence the misidentification and original phrasing of the issue).

So I guess, after a sanity-check that yes, you do have process IDs universally consistent with other system process ID listings, and with the end goal of being able to find a window by commonly accepted process ID... maybe a dedicated windowManager.getWindowsById(...) call? A windowManager.onPid(pid, (window)=>{...}) event interface? Something so I won't need to set up a dedicated polling loop until the window I'm looking for actually becomes available through the API...