well, at least by the end of the year it'll stop getting Wine updates entirely, which is potentially unfun from a pure functionality/features PoV if the problems with getting it working on aarch64-darwin haven't been solved by then. (I do think there are relevant security concerns: e.g. it pulls in TLS libraries and heavyweight media libraries, and has a pretty large attack surface itself as an OS API implementation. though people are mostly running fairly trusted code with it, yeah, and a Wine-only exploit is probably not that compelling for most attackers.)

I don't think CodeWeavers have said anything very concrete. their app itself is universal now, but contains Wine binaries and dylibs that are Intel-only; I would vaguely guess that the future for Rosetta 2 looks either like special codesigning exemptions, or there being APIs for running Intel code but you can't have a full-blown Intel Mach-O binary getting loaded normally. we do know that it at least involves some frameworks being able to interoperate with x86 code at least.

I think the thing about AArch64 Wine on macOS was related to running a native AArch64 Wine to run AArch64 Windows binaries with, right? it seems possible to me that a "Rosetta-only" build of Wine might avoid that, so I wouldn't be surprised if that's what CodeWeavers is targeting.

I think it would be pretty low cost for us to treat it like i686-linux and just maintain the bare minimum required to build up to Wine until it becomes a hassle, especially if we can drop some of the questionable-looking stuff (e.g. we surely don't need SDL or curses support, and if we could do without FFmpeg or GStreamer that'd significantly trim down the closure) and/or do it as cross from aarch64-darwin. just a matter of making that judgement call.