Here’s an up-to-date version of the patch: https://github.com/lukasstockner/blender/tree/scramblingdistance
But guys, please, calm down a bit. Me and the other Cycles devs aren’t complete idiots, if this patch was all happiness, sunshine and faster renderspeeds if would have been committed 2 years ago.
If you listen to anybody who really knows what they’re doing in terms of renderer development (for example at Siggraph just a week ago), you always hear the exact same thing: What a practical renderer needs is consistency and predictable and reliable results. This is why everybody moves to path tracing - you don’t need to tweak 100 different settings to make it work like you would need with stuff like irradiance caching, you just render until the noise is gone and that’s it.
And exactly there lies the problem with this patch - it completely breaks this fundamental property of path tracing. Every Cycles user is used to just rendering until the noise is gone because the underlying math guarantees that you’ll have the correct result then, but with scrambling distance < 1 that is no longer the case. Yes, the image will be noisefree - but you can also get that from Blender Internal or Eevee. The entire point of Cycles is to be a physically based renderer that gives you the right result.
The scrambling patch tricks you into thinking you have a clean image, but you don’t know for sure anymore - with a small scrambling distance, it is entirely possible that an entire room suddenly is 30% brighter because you moved a single lamp by one centimeter. Yes, seriously. Now imaging you’re rendering an animation with an animated lamp. This brings us back to the advantages of path tracing - you don’t get flickering, individual crappy frames in the middle of your animation or any of that stuff - if the render settings work for a few frames in the shot, they’ll work for all of it. Unless you reduce scrambling distance.
I hope this makes it a bit clearer why this patch is so problematic - it’s not just a neat trick like many other features, it completely sacrifices the design goals and fundamental advantages of a path tracer.
Also, just to make sure - yes, if you know what you’re doing, you can get good results with it (see e.g. everything Theory does). However, if you’re an artist hoping to use this feature, you’re not the one who has to handle the bug reports. Oh, and there will be bug reports - we had people reporting “bugs” because they mixed up left and right before and every few weeks there’s a bug that just says “it doesnt work” as the title and has the unmodified default template as the text. For another example, grab a few Cycles materials from Blendswap and check how many of them have two shader nodes plugged into a MixRGB node. The reality is that the people discussing experimental patches here are among the users with the most technical skills and many Cycles users just have no idea what it actually does under the hood. And that’s fine because, once again, you want to have a path tracing renderer so that they don’t have to.
And as a final note - please don’t turn this into another Lukas vs. the other devs thing, we had this a few years ago for D808 and even back then it was bullshit. Just to be completely clear, I 100% agree with the decision to not have this feature in official versions, not even as an experimental option.