Just to clarify a few urban myths you cited.
TLS_FALLBACK_SCSV has an extremely limited usefulness and creates certain interop risks (which the folks who invented the stupid idea of a handshake failure could have easily fixed by continuing the handshake successfully and signalling back to the client, but refused to do).
The only "real advantage" of this it to prevent downgrade to SSLv3, and only for applications which perform a known-insecure "Downgrade Dance" -- which are only web browsers.
The same protection can be achieved by disabling SSLv3 entirely, and this is what browsers did. (Microsoft didn't, but they also do not support TLS_FALLBACK_SCSV), and you can easily disable SSLv3 on the server-side today, if you have a bad feeling about it.
The benefit of TLS_FALLBACK_SCSV for TLSv1.0 and above is sufficiently close to zero, that it is completely irrelevant.
PCI compliance does *NOT* require disabling of TLSv1.0 and TLSv1.1 on the server. Just the OPPOSITE. PCI compliance requires that you enable TLSv1.2, and that the server uses TLSv1.2 when it is offered (something which OpenSSL&Apache fails to do by default). And PCI compliance requires that you _leave_TLSv1.0_and_TLSv1.1_enabled_ on your server, so that PCI-compliant, TLSv1.0-only client will be able to connect!!!
You do not need a risk assessment for your server when leaving TLSv1.0 or TLSv1.1 enabled. This usage scenario is covered by the risk assessement performed by TLSv1.0-only PCI clients, and will only be used with those clients.
It seems that there are a few clueless/broken PCI-compliance scanners (commercial ones) which erroneously flag the availability of TLSv1.0 and TLSv1.1 in addition to a prefered TLSv1.2 on a server as a compliance issue. This is clear defect of the scanner and needs to be taken to the vendor/supplier of that scanner.
-Martin