All of these are pretty high level requirements you have. You may be answering your own questions in that SlimDX is intentionally very low-level, whereas XNA tries its best to answer these high-level requirements, even if the XNA answer isn't necessarily the answer that you particularly seem to be looking for. I haven't worked with SlimDX, so I can only provide some of the perspective of an XNA developer, but hopefully some of it will be useful.
The better questions for XNA versus SlimDX more revolve around things like: which platforms are expecting to support? How much of DirectX do you know? How much of DirectX internals do you care to know?
1) This is a large problem in program design, regardless of platform. There is a reason that text layout libraries are large monstrous beasts. If full, true Unicode support is that important to you, you are ultimately going to need to use non-game-oriented frameworks like WPF, Pango, etc. WPF and/or Silverlight may in fact be a better choice for your game than XNA or SlimDX. (SlimDX does appear to give low level access to the Windows Font API, but using it is rarely as straightforward as you might think and at the end of the day WPF is still Windows' best repository of handling code for dealing with complicated Unicode issues.)
The XNA answer is that you need to find ways to cut down the amount of character graphics you load at once. Worst case that means that you write your own replacement for SpriteFont. (Writing a better SpriteFont isn't terribly hard, and to my knowledge you would need to do something like that in SlimDX anyway.) Most likely you find ways to partition and dynamically load SpriteFonts (that are each individually much smaller than, say, CJK Unified) as necessary at runtime. Certainly XNA doesn't have any direct samples to that effect, but you may find something in the community to help.
The most common answer is really just to constrain your input set. Supporting all of Unicode is hard, but it is easy enough to find common subsets that should make most of your users happy. I'd suggest taking a look at the input methods in various games. You'll notice, for instance, that even in CJK modes something like the Xbox built-in keyboard is going to use just a fraction of CJK Unified... A game isn't a word processor and gamer probably isn't going to expect full unicode support at runtime.
2) There are many .NET libraries that you can find to support various formats. Most of the image formats have good support in the standard library. Music and video formats can be trickier depending on how much you really need them (and which platforms you are looking to support). Again, taking good limits here can drastically simplify what it is that you are trying to accomplish.
For instance, one strong available library in XNA is the MediaPlayer interface:
http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.media.mediaplayer.aspx
This API particularly allows you to interact with people's music libraries on the Xbox and Windows Phone 7 (and Zune). If you want people to provide their own music libraries, on those platforms, that is the API that you must use (there are no other options), and you are going to have to accept its limitations in format support. (Which most people will already be used to and have knowledge of if they are storing portions of the music libraries on those devices.)
On Windows there are certainly many more options for libraries that you can make use of for format support. Finding these libraries are probably going to be the same research regardless of XNA or SlimDX.
3) Multitouch is equally complicated in both XNA and SlimDX. XNA provides a useful multitouch API for Windows Phone 7 (and Zune HD):
http://msdn.microsoft.com/en-us/library/ff434208.aspx
Unfortunately the XNA multitouch API doesn't currently support Windows. On Windows with both XNA and SlimDX you will probably be using the same Windows multitouch API, which to my knowledge doesn't have a good, strong managed (C#) wrapper at all:
http://msdn.microsoft.com/en-us/library/dd371406(VS.85).aspx
There may be third party libraries that you can find, but again, that research will probably be the same regardless of what your framework game is built in.
