Alphakill

I guess the doubled perf is due to some bug/implementation bottleneck in the SPU management code.
There is no accuracy issue when using a cpu with SMT vs a cpu without SMT. RPCS3 is executing PPU threads in separate host cpu threads ; they're not aware of "what" runs them, what matters is that they can use some synchronisation mechanism.

IEEE 754 compliance can be an issue ; extra instructions are required to make compliant cpu (like x64) "uncompliant" one. BTW RSX doesn't follow IEEE 754 norm and it's the root of some gfx bugs.
There's no dedicated Accumulation buffer in RSX. I'm not really sure what the feature did bring to the table though since you can use offscreen framebuffer and blending to achieve similar effect.
RSX supports quads.

Can new instructions like AVX2, AVX512 and FMA3/4 help with compliancy?
So now that Vulkan is out how does it compare to DX12, does it allow better control over rendering pipeline compared to D3D12 and did it expose any new hardware functionality?
DX12 has shader model 5.1 what about Vulkan it seems to still only have SM 5.0 and does Vulkan have support for read-write textures and buffers?

Read/write buffers is a ps3 thing, not a PC/GPU thing; thusly, neither DX12 nor Vulkan support read/write buffers the way the PS3 does. Both DX12 and Vulkan both provide finer grained control over the inner workings of an application, but none add any new features to existing hardware over traditional GL or DX. I honestly cant say either one is better as of yet. Read/write buffers in opengl is not a problem due to API limitations, its just not implemented properly yet. I may get around to it eventually when I have more time.