Within SSL/TLS, the server sends its certificate chain systematically to the client (well, unless the client wants to negotiate a cipher suite that uses no certificate at all, but that's pretty rare in practice). See the TLS standard, in particular this diagram, which says it all:
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
For (much) more complete explanations on how SSL/TLS works, read this answer.
Note, though, that while SSL/TLS formally relies on X.509 certificates, the protocol is not irremediably married with X.509. Within the handshake dynamics, the idea is that the server sends its public key to the client within a certificate chain, and then the client somehow uses the server's public key. How the client obtains the server's public key is a bit out of scope; normally, the client does so by decoding and validating the certificate chain sent by the server, but the client is free to "know" the server's public key from any other way that it sees fit. In some dedicated applications (especially embedded systems), the client may contain a hardcoded copy of the server's public key, and just use that, completely disregarding whatever the server sends as "certificate chain".
Moreover, the "certificate chain", from the point of view of SSL/TLS, is a sequence of opaque blobs, such that the total length does not exceed 16 megabytes. While these blobs are normally encoded X.509 certificates, they may be something else, as long as the client agrees (and a client who ignores the server certificate chain will, by definition, agree to anything). There is even a formally defined RFC for using OpenPGP keys instead of X.509 certificates in SSL/TLS.
IF the certificate chain follows the usual rules (X.509 certificates, that the client validate), then the X.509 rules apply. The complete X.509 path validation algorithm is a work of the Devil to confuse and corrupt good men's minds. However, as a simple summary, an issued certificate (your "intermediate CA certificate") matches its issuer (in your case, the root) through the two following properties, which must all be fulfilled:
The subjectDN field in the issuer (root) must be equal to the issuerDN field in the issued (intermediate CA). Thanks to the multitude of possible encodings and Byzantine Unicode rules for case matching, actual "equality" of names is a potentially complex notion.
A certificate is signed; the signature on the issued certificate must be verifiable with regards to the issuer's public key.
Therefore, if you want to keep the intermediate CA certificate unchanged, then, at the very least, the new root will need to use the exact same name as the old one, and also the exact same key pair. If you change either (or both), then you will need to reissue a new certificate for the intermediate CA.
The same principles apply down the chain: if you change the intermediate CA certificate, then you might still keep end-entity certificates unchanged (the certificates previously issued by the intermediate CA), if (and only if) the new intermediate CA certificate still contains the same intermediate CA name and intermediate CA public key.
