No, that CU is for instances that are running SP2, so service pack first, then CU

User B starts the update immediately, but will probably be blocked until User A's session releases locks, which will be when the transaction commits.

Yup, case-sensitive is the cause (and that's why I'm allergic to case-sensitive databases).

The name of the dmv is sys.dm_db_index_physical_stats, all lowercase. You'll have to fix the casing of...

I never clear caches, and run queries twice before measuring to ensure caches are hot.
Reason: my application doesn't run with cold caches.

Ah, I just noticed what you're doing.

You're never updating that long column name, you update NbCum, then try to alter the long column name, and it still has the char(160)...

You're not running in a transaction, so no, you don't need a COMMIT (and you wouldn't even if this was in a transaction)

It's possible that the whitespace character...

Could be that the full backup file was damaged in some way. Do you take your backups WITH CHECKSUM? Can you try a fresh backup?