Can an SSL client send CLIENT HELLO with version 3.2 and NOT negotiate 3.1?
There is a theoretical way which is explained in appendix E of RFC 5246; but its implementation is not necessarily easy.
In the ClientHello message, the client sends a "protocol version" which is the highest that the client supports (and is willing to use). This includes the implicit message "but I may support some older versions as well". The server then chooses the version which will be used, and states it in its ServerHello message. For instance, the client may have sent "up to TLS 1.1" (encoded as 0x0302) and the server could respond "we’ll do TLS 1.0" (encoded as 0x0301).
There is no way for the client to proactively announce exclusions (as in: "I support TLS 1.1 but I don’t want to do TLS 1.0"). However, if the server tries to use a protocol version that the client does not want to support, then the client always has the possibility to close the connection. Appendix E says that:
If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection.
In all generality, if the client wishes to support only a non-contiguous set of protocol versions, then he can enforce that by dint of using several connection attempts. For instance, suppose that, for some reason, the client wants to do TLS 1.1 or SSL 3.0, but not TLS 1.0. In that case, the client may first send a ClientHello specifying TLS 1.1 as highest supported version, and, if the server tries to use TLS 1.0, the client may close the connection (preferably with the "protocol_version" alert message), and then connect again, this time sending a ClientHello specifying SSL 3.0 as highest supported version.
This works only if the usage context is such that the client can attempt several connections (e.g. we are talking about HTTPS, with TCP connections that the client can open at will).
In practice, a server or a client usually supports a contiguous range of protocol versions (e.g. supports TLS 1.1 and 1.2, but not 1.0 or SSL 3.0). In that case, a single handshake attempt is sufficient: either the server will choose at the first try a protocol version which will be acceptable to the client, or there is no version which is acceptable to both client and server and it will never work.
Whether a given implementation of a SSL client offers an API to disable support of an old protocol version, is another question, of course.