Mechanism for passing dir/cwd and env to w64devkit.exe

Could there be a sensible mechanism for directing w64devkit.exe to start in a passed directory? And the same for passing env vars?

I use wt (Windows Terminal) in some of my shell functions to control the terminal emulator itself (new tab, window, split pane...). Terminal is set up with w64devkit as default profile, so new instances always start with busybox's login shell (see #186), which understandably always starts in $HOME and with a fresh env.

This severely limits the use of calling w64devkit.exe and using it in workflows, since it always starts fresh. (I mean, that is it's purpose!)

At first I thought the workaround would be to call wt C:/path/to/busybox.exe sh -i (or without -i, and god forbid you have a space in that path cuz wt doesn't accept quoting here), but this has many problems. It ends up running a shell in a shell (the indirection is felt by the wt window not closing if the busybox sh -i instance exits uncleanly; it doesn't continue in the default profile w64devkit's sh -l instance on exit), and the new shell-in-a-shell ends up not sourcing ~/.profile since it's not a login shell (huh? what about the parent sh -l? I dunno!)

This situation also means that with w64devkit as default profile in Terminal, the Open in Terminal context menu item is broken (since it indeed does not open the Terminal there), as well as the File Explorer address bar shortcut ("cmd" or "wt") not getting to pass the cwd along. (EDIT: Windows Terminal's "Starting directory" functionality, including "Use parent process directory", for profiles is also obviously broken for w64devkit for these same reasons.)

The fix here could be to have w64devkit.exe accept a flag like busybox sh (-i) which starts a non-login shell... Well, actually, that wouldn't work either, would it? Since then you end up with a non-sourced shell again.

IN CONCLUSION: To integrate better and allow many more workflows, w64devkit.exe should have a switch to create a shell which 1) inherits its env and 2) executes the startup files. (I think? Maybe the other way around? Maybe configurable?)

Start at the w64devkit.exe process-launch entry point and trace how it starts BusyBox's shell. Compare the requested directory and environment behavior with the startup-file behavior described in the issue and the linked Bash startup documentation. Done means the issue's requested workflow has a defined, tested mechanism for passing cwd and environment while running the intended startup files.