First, due diligence: are you sure you're actually running 64-bit? By default new projects get that dumb "Prefer 32-bit" option checked, so an AnyCPU build will still run using 32-bit. Also, make sure if you've got the debugger attached that you don't have it set to inhibit optimizations. By default most optimizations are disabled even in release mode when a debugger is present, for obvious reasons.
Also, be careful about which package you're using. The JIT looks for a very particular assembly to enable intrinsics, so if there is a mismatch in which build you're using it will just not optimize it. Doesn't .NET 4.6 ship with an older System.Numerics.Vectors assembly built in, or is it still recommended to grab one from NuGet?
It's been almost 8 years exactly since my first commit. I was 17 at the time, still in high school, and therefore had a ton of free time on my hands. You can see in that initial announcement thread that I found myself interested (I had only recently gotten into C# and was playing with MDX). I PMed Promit, offered to work on DirectInput and got commit access (suspiciously easily actually. I think the idea of avoiding DirectInput work outweighed the fact that he didn't know me very well).
I didn't know C++/CLI at the time. It's an incredibly bizarre language and I'll do anything in my power to avoid using it on any project I ever work on again. I dug up an old journal entry where I list a few random quirks and then this one where I talk about the insanity of friend assemblies in C++/CLI. Fun times.
The fact that I had so much free time first in high school and then in college after that meant that I ended up doing the bulk of the tedious wrapping code. Poor Promit and jpetrie already had day jobs and had to come home and put in more work at night. From looking at the repo, I was responsible for Direct3D11, DirectInput, DirectSound, XAudio2, RawInput, X3DAudio, XAPO, D3DCompiler, Direct2D, and DirectWrite. Also lots of other random junk; the D3DX animation stuff is still a distant nightmare for example. We also ended up with a collection of neat little tools; one for counting lines, another for generating release notes, documentation, and website junk. There's one in there I remember writing to work around a crash in Microsoft's PIX tool where you couldn't run it on managed x64 assemblies.
At some point I made us an icon; it's been set as my avatar image ever since.
As Josh alluded to earlier, we had a great persistent bug in our memory allocator that we eventually tracked down. It's one of those ones that will stick with us probably forever. I eventually went back and replaced that whole system with the one that's still in use today. We very often need temporary space when marshaling parameters, so stack allocating that space is key to good performance. Unrelated: when wrapping some of the hairier parts of DirectInput I took a look at what MDX used to do and discovered some hilarity.
Right around the end of 2009 / beginning of 2010 development started to slow down. The library was stable, fast, and covered almost everything in DirectX, and a good deal more on top of that. Shortly after that MS released the June 2010 SDK, which was the last DirectX SDK drop. We worked for another year or so polishing things up, at which point MS announced Windows 8 and discontinued the SDK. Nobody on the team was interested in Windows 8, so we went into what was essentially maintenance mode.
Working on SlimDX was a ton of fun. It felt good to be working on a project lots of other people would actually find useful, and probably cemented in me my love of developing libraries and middleware. Every once in a while we'd discover some game or project was using our library. That SlimDX.dll would pop up in very surprising places over the years.
Working on the project was also a great way to network; I joined the #gamedev IRC around that time and got to know jpetrie, Promit, and Washu pretty well. Later on jpetrie recommended me for a job at ArenaNet out in Washington, so SlimDX was essentially my ramp into the games industry. The number of people I'd randomly meet who knew of the project was surprising. When I was at ArenaNet, we'd occasionally interview people who had used the library and had listed it on their resume. When we interviewed our audio programmer he started talking about how he had used it for his own personal audio projects he was working on. Going back further, one day I was in class at school, and the kid in front of me had the SimpleTriangle tutorial open and running on his laptop. We ended up becoming friends and roommates for the rest of my three years there based on that.
The SlimDX team has since moved on to different things, but I think we all still look back fondly on the project. We stepped up at the right time and provided a good product for people who needed it. The last binary release we did, in January of 2012, has over 500,000 combined downloads. I don't know if we'll ever take it further or even if we'll work on something different together; Josh is off in OSX land these days and Promit is swamped with shipping indie-ish games for mobile. I've been helping out with improving and wrapping a low-level graphics library developed by a former ArenaNet colleague. I feel like this is probably the way to go for any future game projects I work on.
Thanks for the interest; it's always fun to take a trip down memory lane.
Pango is a higher level library that draws together a collection of lower level libraries, including FreeType. You can do much the same thing yourself by just pulling in what you need. For the advanced OpenType shaping and layout stuff (GPOS and friends) you want the HarfBuzz library. DirectWrite is basically a combination of HarfBuzz and FreeType for Windows (with other stuff thrown in, like higher level font selection based on family names). It's not a great idea if you need to be cross platform though, as you've mentioned.
Most games don't even bother with scalable glyph rendering like you get with FreeType, let alone go into even more advanced layout and shaping, which is why you're going to have a hard time finding resources on it. Even with those libraries, applications like web browsers consistently have a hard time getting things perfect for all of the languages they support.