@Aaron Carlisle (Blendify) please correct me if I'm wrong, but closing this issue because Blender Render was removed doesn't make sense to me, because you can perfectly use Cycles to bake textures.
But I'm ok with it because it is not a bug but more like a feature request.
For all interested in producing dithered textures, there is a workaround:
Newer GIMP versions support dithering when converting from 16 or 32 bpc to 8 bpc.
So you can bake 32 bit textures in Blender, export them as exr, open the exr file in GIMP, convert to 8 bit with dithering, export as PNG.
Not very streamlined but it works.

I tested this on Linux with various file formats and libopenimageio 1.8.12 .

I'm happy to say that with current builds (b0823962e9b) this issue is solved. Both methods converge now. The final picture is a bit different from both pictures I originally posted:

I'm not sure if it is float precision issue, but one can see pretty quickly (after 4000 or 8000 samples) that it will converge to a different result.

The issue still persists here with build 0f793ee. @Brecht Van Lommel (brecht) did you render my example .blend file before closing this issue?

The new if statement is working for me :)

I made some progress:
After inserting some printfs in the block starting at line 464 I made these observations:

After upgrading to gcc-5 and gcc-6 I was not able to produce correct renderings anymore (with the -flto trick I used in gcc-4.9)
So I looked at the code in intern/cycles/kernel/closure/bsdf_microfacet.h

Sorry for the noise. I came to the conclusion that my understanding of correct and incorrect is wrong.

Yes I compiled it myself, hash 89df672.
Hmm, thats strange: To produce correct indirect diffuse color, all RGB channels have to be non-zero.
If only one channel is non-zero then the result is always grey. (although there are different colored objects that should reflect their light onto the baked object)
Can someone confirm this?

Seems that baking produces wrong results only for the RGB(1; 0; 0) diffuse color case.
The intermediate values are ok.

I can reproduce it on Debian.
But the patch doesn't fix the problem.
Before the patch the direct light was buggy.
After the patch the indirect light is buggy.

@Sergey Sharybin (sergey), I just tested the gcc5.5 glibc 2.19 builds. There is no improvement unfortunately.

Finally I'm able to build Blender myself.
The cause of this issue seems to be optimization done by gcc.

Why not make this an option? I used the old orbit behavior to quickly setup the camera for axonometric projection (useful for isometric games and tile rendering).
Now this is much more complicated.

I tested build b336124 on the same hardware (AMD Llano APU), but different OS:

@Sergey Sharybin (sergey), I tried your suggestion with the Debug panel, tested every combination of SIMD flags, and without any SIMD flags, with and without QBVH, but unfortunately nothing has changed.
I can't test the OpenCL kernels because I have a pre GCN (graphics core next) APU, which is not supported by Blender.
A strange problem really, with no solution in sight. I'll try to test it on some other systems and report back.

I still have this issue with the buildbot version on Debian. buid-date: 2015-11-27 hash: bafccb0

@Sergey Sharybin (sergey) This happens in both, viewport and final render. Worked fine in 2.71
Here my system-info.txt:

I can also confirm this bug. It seems that some but not all faces get rotated by 180 degrees during baking.
Here another example .blend:

I experimented with clamping roughness to zero if it is less than 0.000173.
Seems to work well.
Not a real fix but a workaround.

Hmm..., maybe the issue is OS, or compile flag dependent.
I use the 64 bit Linux builds from buildbot.
@Carlo Bergonzini (Carlo) Andreacchio, @mohamed (mohamed) Sakr: what OS are you using?

Yes this still happens with latest git HEAD.
I use CPU renderer on AMD Richland APU.

Thanks, for the explanation, Bastien.
I found a setting in the preferences called "Use 3D Viewport" (Screen->Render). I had to deactivate it for my purposes.
Still for quick preview renders we could have another shortcut like ALT+F12, because I think many artist are not aware of this feature.
Just my opinion.

Press F12 to render it. (The viewport doesn't respect the new "Clip" option. It always has the "Repeat" mode. Maybe I should file a separate bug report for this?)
I'm using a second UV map called decal.
The sphere should mostly be covered by the sand texture. Only in the middle it should have the stone texture.

@Alexey (Inwader77) I think what you describe is dithering after rendering, which is functioning without flaws (Dithering is applied on the "Composite" Node).
What I mean here is dithering the texture after texture baking.

Thank you, Sergey! Waiting for the OIIO fixes.

@marc dion (marcclintdion)
Of course dithering should be an option. My last post could be misunderstood.
Right now dithering can't be applied on "Save Image", no matter what options you choose.

I think the solution for this problem is not a Cycles specific fix, but a general fix for the export routine for byte images.
So when you save a float image to a byte image, dithering should be applied (as is done when you render).

@Sergey Sharybin (sergey):
Brecht already fixed TIFF and TGA.
Formats that are still affected are: DDS, JPEG2000, IRIS and DPX

Thank you for the fix, Sergey!

It seems that the "Image Drawing Method" in File/User Preferencies/System plays a significant role here.
GLSL is probably the most stable method (no crash so far), but it's slower than the other methods.
"DrawPixels" and "2D Texture" both cause this segfault.

After a second thought it might be a bug.
Blender 2.69 consumes 26 percent of my 2GB with a 4000x4000 image.
So why should the current development version crash?

Tested again, It's not a problem with the image loading, but with image viewing!
When I enable Backdrop or Show Viewer-Node in UV-Editor then Blender consumes very large amount of RAM.
Another thing I found out is, when I change the "Image Draw Method" to GLSL, RAM consumpion improves dramatically, and I can handle 8K Images on my 2 GB RAM system.
(though Draw Method: "2D Texture" seems to be a bit faster on my system)
But still the current version seems to consume more RAM than 2.69.
So it's not a real bug, but maybe improvements to RAM usage can be done some time in the future.

I tested it again on another Linux computer with 8 GB RAM.
To achieve the same crash I needed to resize the image to 8000x8000.
Thomas could you please test it again with test_image8000.png?

I'm pretty sure I'm not running out of memory. (My swap partition would cause a significant slow down otherwise)
Instead, Blender crashes immediately, without touching the hard disc.
And 2.69 doesn't have any problems opening the test image.