Buried in the 1.3.4 announcement is a tiny, insignificant little change that makes it possible for distributors to package Mono for Wine:
mscoree: Search for Mono in some predefined paths before using the registry.
As happy as I am to have sneaked this in under the radar, as it were, I guess I'm going to have to tell someone if it's ever going to be useful.
I have no plans to make an official Wine Mono distribution. It should be easy enough for anyone to build.
We currently do not require any changes in Mono for use with Wine. When we do (and it will be soon), I will try very hard to get the things we need merged upstream. Any managed libraries we need instead of or in addition to those shipped with Mono will have to go in Wine. We don't need a fork yet, and I hope we can keep it that way.
Mono installs are generally self-contained and do not interfere with each other. Mono does not have to be installed into a bottle before it can be used. Therefore, I have not programmed any sort of install process into Wine. It will simply search for Mono as needed.
If you are a distributor, here is how I recommend you distribute Mono for use with Wine:
Download and extract the mono 2.6.7 source tarball from http://ftp.novell.com/pub/mono/sources/mono/mono-2.6.7.tar.bz2
Use the instructions at http://wiki.winehq.org/Mono to cross-compile Mono 2.6.7 using mingw32. Tweak the script if you have to (or just want to), but consider contributing any fixes you have to make back to winezeug.
This will create a directory named mono-2.6.7. The contents of that directory should be installed to /usr/share/mono/mono-1.0.
To make sure this worked, you should try a simple "Hello World" .NET application in Wine. Wikipedia has an example at https://secure.wikimedia.org/wikipedia/en/wiki/C_sharp_programming_language#... that you should be able to save as a .cs file and compile to a .exe file using gmcs. If all is well, you should be able to run that exe file in a clean Wine prefix.
In the future, we'll need a mono-2.0 directory as well, so we can keep using newer versions of Mono and get .NET 4.0 support. But we're not there yet.
In case all these numbers have not confused you yet, the current version of Mono is 2.6.7. This version uses the Mono Embedding API version 1.0, which is why it needs to be placed in a directory named mono-1.0. It normally includes .NET 1.1 and 2.0 runtimes. It can optionally be compiled with a 4.0 runtime as well, but I don't recommend it.
I'm expecting to see Mono 2.8 released "soon". That version will use the Embedding API version 2.0, which Wine can't support yet, but when the time comes it will need to be in a directory named mono-2.0. It will include .NET 2.0 and 4.0 runtimes.
.NET 3.0 and 3.5 are not runtimes, which is why they were not included in that list. They use the .NET 2.0 runtime.
While Mono 2.8 (and eventually 3.0) is the way forward for .NET 2.0 and 4.0 support, we'll need to also have the 2.6 series available so that we can have a .NET 1.1 runtime. Wine will detect which versions are available and what runtimes they have using a system that I'm working on and hope to have ready "soon", and it will select the correct runtime for whatever it's trying to run, or whatever the program selects using the .NET embedding API. (Also coming soon: the .NET embedding API.)
I'm treating Mono as an optional dependency, much like the many native libraries Wine already uses. If it's not there, Wine will gracefully report failure to applications that try to use it, which probably won't work, and print some things to the console. I plan to send some changes soon that happen to cause a Wine without Mono to fail some tests, so I do consider an install that's missing Mono to be broken. But for the most part, the user experience will remain the same as it was before if Mono is missing.