A->B : {I_b - 1}^{CK} : TGS_REQB
As far as I understand, the choice between I_b + 1 or I_b - 1 is arbitrary by the protocol designer, as they both equally prove that A was able to decrypt I_b using CK.
However, from what I remember, this isn't part of the TGS exchange; rather it's part of the AS exchange, as part of the "pre-authentication" or "preauth" feature in Kerberos 5.
TGS changes session key CK to CK_b?
Not exactly. The CK is not global state; it belongs to the ticket that it was issued with. The full name of 'CK' was originally "conversation key". So it isn't that the CK is "changed", but rather there are multiple CKs co-existing.
During the AS exchange you received a ticket for the TGS service with its accompanying CK_A_BTGS, and later during the TGS exchange you received a ticket for the other service with its accompanying CK_A_C.
So you should divide your example process into three "conversations":
The AS exchange (A↔BAS) uses the client's long-term key K_A to obtain a single ticket and its accompanying CK. This ticket is usually the TGT (i.e. ticket for the TGS).
The initial AS exchange is special in that there's no pre-existing CK to protect it, so it's only protected by the client's long-term key KA.
The TGS exchange (A↔BTGS) uses the 'krbtgt' service ticket (and its accompanying CK_A_BTGS conversation key) to obtain a ticket for the final service (with its accompanying CK).
Further exchanges (A↔C, A↔D…) use the obtained service ticket (and its accompanying CK_A_C conversation key) to authenticate to the whatever final service.
It is possible in Kerberos to use the AS exchange to obtain a ticket for any service, in which case step 2 would be skipped. This is used e.g. for the 'kadmin' or 'kpasswd' protocols, both of which use AS_REQ to directly get tickets for the respective services (for policy enforcement reasons). That makes it even more important to treat the AS_REQ/REP and TGS_REQ/REP as independent stages.
As another example, the XNS Authentication Protocol (of the Xerox XNS platform), which predated Kerberos, didn't yet have separate AS/TGS and the user's long-term key ("strong key") was directly used to request all service tickets.