That being said, I think he is overestimating the market that would pay for this. This seems like it could attract at least a small community as an open source project, however. Unfortunately effort in development is not always rewarded with monetary gain.
Perhaps he should license it as GPL3 and offer commercial licenses? He may find some customers in software houses that are still selling Win16 software.
His approach is a bit different as he is shimming 16 bit APIs to their 64-bit equivalent. Wine reimplemented them to run on top of a POSIX environment.
His approach will result in higher fidelity for apps as they are basically running on Win64, just with a 16-bit virtual machine driving it.
Wine apps running on Windows would likely feel non-native as the UI components are reimplemented from scratch.
Wine actually has (mostly) functional theming support-- point Wine to a .msstyles theme DLL and it'll draw themed controls (rather than the Windows Classic style default).
They just don't ship a theme with Wine; understandable for licensing reasons (they can't distribute Microsoft's designs), but it means that Wine looks like Windows 2000 out of the box.
I find it a bit amusing that were they to "update" their look to that of the flat Windows 8+ UI, it would probably entail the removal of a lot of code.
...and yet even on a 25MHz 386, no one complained about the slow drawing speed of the "fancy" 3D buttons in Win3.x.
Well, modern flat design generally also includes a much more animated interface, which would probably entail the addition of much more code. And I don't think the drawing speed of buttons was ever a very strong reason for the rise of flat design - though I completely understand your distaste for it.
16-bit applications can't run in long mode (i.e. a 64-bit OS), so you'll need a 32-bit OS to run these apps in WINE. WINE is just a shim and a library reimplementation, not an emulator, so it just passes the instructions on to the CPU, and you're limited by what the CPU can do.
Hmm... I wonder if you can run 16-bit applications in WINE on a 32-bit VirtualBox VM running on a 64-bit Linux system. That sounds like overkill, though. Might as well just use PCem or DOSbox, depending on your use case (PCem: cycle-accurate emulation of a whole PC, including specific hardware models and running any OS a real PC could; DOSbox: playing some old games for fun).
TBH, I'm not sure what win3mu's point is, either: it probably won't be open-source, and right now the only reason to not use PCem or DOSbox is if you don't own a legitimate copy of Win3.1 and you're not willing to pirate it. An open-source clone of Windows 3.1 that can run any Win16 program in long mode (by interpreting the instructions like an actual emulator) would be a great idea, but this isn't it.
But yeah, I don't think it's explicitly supported since it's not their target market :) Codeweavers' focus is running Windows apps on Mac and Linux (Crossover - go support them! https://www.codeweavers.com/)
Edit: It looks like they completely dropped support for it as I can't find any of the old articles anymore; Seems it only supports mingw setup now. https://wiki.winehq.org/Cygwin_and_More
Crossover is a commercial version of Wine which includes a bunch of extra hacks for popular applications. It comes with support. It's how the Wine project pays salaries.
PlayOnLinux is a Wine wrapper which has preset configurations (best known working wine version and dll overrides) for a ton of popular games/software. Think of it like a virtualenv on steroids.
That being said, I think he is overestimating the market that would pay for this. This seems like it could attract at least a small community as an open source project, however. Unfortunately effort in development is not always rewarded with monetary gain.
Perhaps he should license it as GPL3 and offer commercial licenses? He may find some customers in software houses that are still selling Win16 software.