Meta: SE policy is generally against multiple questions in one post. But here your second question is a duplicate of Triple handshake attack against TLS which I already answered, leaving one open question.
The wording in the glossary of rfc 5246 (and its predecessors) may be a little lazy, because you are expected to pay attention to the whole document. The actual point is that a (TCP) connection is associated with one TLS session at a time. The time sequence is:
To start TLS/SSL, you make (or sometimes already have) a TCP connection and either do a full handshake to create a new session or do an abbreviated handshake to resume an existing session (if there is one available). After that initial negotiation, all the data transmitted and received is encrypted (unless eNULL) and authenticated using keys derived from the master_secret for that session (plus current nonces), and should be treated by both sides as having the security (and other) parameters of that session: master_secret, algorithms, server authentication usually, client authentication if used, and TLS-level compression if used, which was never very popular and after CRIME is often prohibited completely.
Any later time during the same connection, if both endpoints agree, you can do another handshake called renegotiation on the same connection. This renegotiation again can be a full handshake that creates a new session or an abbreviated handshake that resumes an existing session. In the resumption case it may resume the same session that was in use before the renegotiation, or it may be a different saved session. Once the renegotiation is done, subsequent data uses the keys and parameters of the session selected by the renegotiation, usually though not necessarily different from the session from the initial handshake.
At a still later time you could do a second renegotiation, again with the same features. After that, data uses the keys and parameters of the session selected by the second renegotiation, probably different from the session(s) from the first renegotiation and the initial handshake.
Et cetera, et cetera, et cetera.
After terminating one connection, you can make another connection that again can either create a new session or resume an existing one, if it is available; often endpoints drop a session after a time limit like 5 minutes or 1 hour, or if they run out of space, or have an error. And again, and again. You can also make several connections concurrently, each of which can either create a new session or resume an existing one. And after terminating them, you can make more, ditto.
Nowadays renegotiation is usually done when one party, usually the server, wants to change the security parameters, such as to do client authentication which was not done on the initial handshake (or prior renegotiation). In order to change security parameters, the renegotiation must be a full handshake.
But the protocol allows the renegotiation to be an abbreviated handshake that resumes a session. The only obvious valid reason for this is if you have encrypted enough data under one working key set that you want to generate new working keys, traditionally called rekey[ing]. With CBC mode it's best practice not to exceed the "birthday bound" of sqrt(2^blocksize) blocks under one key, and for 3DES (and DES in the years before it was obsoleted) this is 2^35 octets or 512GiB. With modern networks under sustained load you might reach this volume, and want to rekey, in about an hour or maybe less, and even under lesser load this could easily occur in days or weeks.
