I totally get your point but we are great at running old windows now with dosbox and wine.

For now, but maintaining DOSBox and especially WINE continues to require substantial engineering effort, in part because the platforms they're running on change. Implementing Uxn/Varvara is many orders of magnitude easier than implementing Win32, as evidenced by the fact that many more people have done it despite the much smaller base of applications they can then run. It seems likely that many Win32 applications will execute incorrectly on versions of WINE that are current in 02124, unless they themselves are running on top of something like Uxn.

Probably not Uxn itself, though, because a 16-bit memory space is not a practical way to emulate Win32. Dmitry wouldn't be dissuaded, I suppose.

I understand the argument, and feel good about it. I too would rather our software was made with simplicity and performance in mind not only following the premise that hw resources will only increase so let's ignore those constrains today.

But another perspective for win32 support in future metal is the bigger "community" (users, software, etc) so the increase in support complexity is compensated for much (much) larger incentives for supporting much more diverse and desired old software. WINE and related SW is a testament to this

It might work out that way, or it might not. The current open-source community is very much a product of current social conditions, and those conditions might change. They've changed before, and could change again.

Things like LLMs and the xz backdoor, for example, may make it unappealing to accept code from people you don't know personally; things like Apple's notarization requirements may make it impractical to run open-source software except as part of a proprietary package; software patents or legal liability for third parties using your software could make it legally unappealing to free your code; etc.

Not a problem. You can simply emulate Windows, then emulate Uxn within Windows.