Well just an FYI it also removed my SWAPWAITTIMEOUT setting and something else
No, it hasn't.
As I've said, the installer removes ONLY the [BufferPools] section. The SWAPWAITTIMEOUT is NOT touched by the installer or the Addon Manager.
The Addon Manager is *able* to change the setting, but it won't do it automatically. It will only do it under YOUR command, when you press the "Save to FSX" button. If you don't press that button, the FSX.CFG is not changed.
The bufferpool tweak is something I won't touch with a 10 foot pole but to honest
Exactly. It doesn't exists by default, which is why the installer correctly removes it, because it has been proven to be dangerous.
I flew a round trip without it (KMEM-KIAD) and it was not smooth at all compared to previous settings.
It's possible that, depending on your combination of video drivers and settings, the bufferpools might not crash your sim, and even make it smoother, but since we proved it WAS causing crashes for lots of users, and it's also very well known it could be dangerous, since by default that tweak doesn't exist, we simply cannot afford to leave it enabled.
All I am trying to say is outside the AF=14 (which I guess I can try), there is something causing these pauses and it is, if nothing else, slightly discouraging that FSDT is just going to say "its ok" especially if KMEM is going to be the start of a new direction at FSDT. Is the new KORD or the next FSDT announcement going to have this same stutter? Just makes you go hum 
You seem to believe your computer has "infinite" power. It doesn't. KMEM is several times more complex than anything anybody ever did in flight sim. If someone else would tried to do it just the same, it won't EVER fit in memory. In order to have it fit in memory something that will never do, normally, we must create and destroy objects, and there is already A LOT of code that PREVENTS stuttering, but there's a limit to what we can do with it, objects must be created and destroyed, eventually.
Once both sims will be 64 bit, we might do memory-management less aggressively, so the same sceneries with probably work much smoother by then.
It's the clear case of wanting to eat your cake and have it too: if you want a smoother scenery, you have to allocate *more* memory. If you want to prevent OOMs, you have to *save* memory, which means destroying unused objects as soon as possible, and this will create some minor stuttering.
I'm assuming it's minor, according to your own "almost not noticeable" wording, which seems do indicate we reached our goal, of displaying a scenery more dense than anything else out there, and save you from OOMs at the same time.
And just to be more clear: when I said "a scenery more dense than anything else out there", you should take the scenery area into account. KMEM is mostly made of huge empty aprons, and if we used an object density comparable to any other scenery out there, it would looked like a ghost town.
