What is the use of SSS's blue response?

I've seen it in Poser's Firefly, and now also in DS Iray, Sub Surface Scatter turning blue/green when the mesh turns in on itself and the vertices are in very close proximity of each other. Why does that happen, and more importantly, why do they let that happen? Because I cannot see any use for it, and I'm pretty sure something can be done to prevent it. Right now in Poser all you can do is hope that the adjacent mesh belongs to a different material zone, then you can set he different scatter groups, but other than that, why blue? Can't they make a simple rule/calculation that if vertices are in a certain proximity of each other that that they scale up the SSS... or at least kill the blue effect?

I can only answer why blue. It's whatever is the complementary color of the scatter color you've selected. The complement of the mostly red skin tones is mostly blue.
The reason is not something I fully grasp but I can spit words out I've read before.
The scatter is faked. It is not literally scattering rays around, but instead doing an approximation. Yes, this means SuperFly is not an unbiased renderer because unbiased renderers do not do approximations and Cycles/SuperFly do.
Anyway, the fake is implemented with a mathematical object called a "dipole" that approximates a diffusion of particles in an analytic fashion. "Analytic" here means that it uses a simple formula that gives a straight answer in one step, instead of a gigantic simulation of millions of steps.
As with any approximation, it is not an exact match for the reality, and in some circumstances, not even a decent match.
I do not understand all the math but it involves pretending there are a pair of glowing something or others on either side of the surface. This is the dipole  a pair of opposites, like north and south on a magnet. One is the scattering color (in our case, reddish) and the other the opposite absorption color (in our case, bluish). The two "pretend" light emitters are then used to derive the answer.
When surfaces bend and pass near each other, these dipoles cross over and stick out the wrong side of the nearby surface, and the "south" pole then sprays blue over the wrong place.

More (better) info:

@bagginsbill ok that makes a lot of sense, thank you, and I'm also not claiming to be any kind of chromogeometric genious, but that explanation in itself reveals the answer that should be able to solve the problem, wouldn't you agree? If this dipole cross over and influence deep enough to make the opposing side of the mesh blue, the fact that the mesh actually turns blue shows that the math has done its work... now just reverse that and discover whatever entered into this 'bluemaking'zone and stop the dipoles from doing their damage much like making the opposing geometry part of a different scatter group, with some proximity method or something. If it takes more calculation time, make it an option then. Either way, this blue thing is annoying and mathematically necessary, don't you think?

As I said I don't understand the math and cannot explain how the thing actually works, nor what equation is actually producing the artifact. It's known (by the users) and yet unacknowledged (by the authors) that subsurface scattering using dipole approximations just doesn't work when the pole distance is larger than the diameter of the object itself. When that happens, the negative pole is actually outside the volume. This is easily seen here:
Cycles SSS seemingly incorrect colour for thin surfaces or small objects

Note as we've heard absolutely NOTHING from the new product manager, I cannot tell you if the remaining engineers even have the math skills to tackle this issue on behalf of the Cycles designers who clearly don't.

@bagginsbill ah well we will have to see then. Its not the worst problem in the world as there are ways to fudge it I suppose, but yeah I don't see how this cannot be fixed down the line somewhere. Math is the language of reality, the sloppier the translation, the more abstract our depictions of it will be.
Thanks a tonne for the info in any case!!!

Essentially, subsurface scattering is a volumetric effect. You're trying to calculate the light that has entered an object surface, bounced around for any number of times inside the object, and finally exited the object at a different point. Ideally, you'll need the contribution from all light that hits the object anywhere, as SSS is not a local effect (if could put the sun in my nostril, my toes would glow from the scattered light).
Now, one could calculate that effect in a brute force fusion: just trace lots of random volumetric bounces inside an object and wait for a very long time for the render to finish. That is certainly possible, it will deliver accurate results and can be achieved in SuperFly by using the volumetric nodes with very high density values. Note that the accurate calculation will now make other approximations visible, notably that bump maps or smooth shading are just a hack to replace real geometry. Be prepared to either see facets or to use lots of subdivision.
Since the brute force method is not very practical (and certainly was not 15 years ago), a very clever approximation was introduced: the BSSRDF. It's a function, that given an entry point and an exit point for light, calculates the scattered light that travels between those two points. There are several BSSRDF functions out there, such as the dipole (FireFly's scatter node), sum of gaussians (Subsurface Skin in both Fire and SuperFly, Cycles SSS node), or Burley's Approximation (Cycles SSS node). A limitation that they all inherently have is that they have no knowledge of the geometry of the object  all they have is two points. And they all rely on the assumption of fairly dense materials compared to their size and are approximating a semiinfinite flat object. This is why they fall apart when the scatter radius approaches the object size.
In order to calculate the integral of the BSSRDF over all light reaching the object, one can either do a prepass and gather light over the surface (as done by FireFly) or one can just randomly pick points on the surface on the fly (as done by SuperFly). The latter can be done in unbiased methods, but then you're only getting an unbiased estimate of a function that approximates scattering.
PS: It is a very common misconception that "unbiased" means "correct"  it doesn't. The importance of bias (or the lack of) in light transport is mostly academical and rarely has any practical implications. See http://cs.au.dk/~toshiya/misc.pdf for details.

Regarding the brute force method: Disney has used that on occasion where the diffusion approximation wouldn't cut it, notably snow and ice  see page 10 in this document: http://blog.selfshadow.com/publications/s2015shadingcourse/burley/s2015_pbs_disney_bsdf_notes.pdf
Skin in most productions though is rendered with the same methods available in SuperFly  it implements state of the art methods such as BSSRDF importance sampling*:
https://www.solidangle.com/research/s2013_bssrdf_slides.pdf
and Burley's exponential BSSRDF:
http://graphics.pixar.com/library/ApproxBSSRDF/paper.pdf*The weighted sum BSSRDF for skin in the slides has been in Poser's Subsurface Skin node since the beginning, as the method has been around for a while. See https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch14.html

This is roughly how I'd do brute force skin scattering in SuperFly.


Yay! Stefan is here.
I have noticed that in SF, Burley and the PhysicalSurface don't show blue so easily (or at all), while Cubic and the Custom_Scatter node do it rather severely. Should I be telling people to just stick with Burley and stay away from the others?

I don't see any reason not to use the Burley BSSRDF. For what it's worth, Solid Angle removed all other options from Arnold 5 and the (as they call it) empirical BSSRDF is now the only profile it offers.

@stefan I was experimenting with Burley SSS in PP11 here on Baby Luna. I am impressed, especially since I am no material room pro, but I ran out of time to play.

very interesting to read and check up on @stefan thank you for your time explaining that!