I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing.
does rm have such an option ? rm doesn't, so I don't see any reason for this code bloat if you want to be paranoid (or you distro want to be), do it in wine script (or in the .winewrapper extension)
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
that could bring some issues while trying to run a native executable from a mounted FAT driver (without the proper umask option for mount) (this could be circumvented by a drive configuration option in wine, but that would be a bit tricky to set for the average user)
Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so.
IMHO (regarding Klez), the main issue is the mail client not wine. It should protect/warn the user about this, not forward the blame on others
And as for making "/" available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
I think this a more interesting alternative. People did start working on that (especially for SMB shares mounting) A+