Gatling 3.10 changed the httpProtocol caching default — do upgraded simulations need explicit disableCaching?

I'm reviewing a Gatling simulation suite that was written against 3.9 and recently upgraded to 3.10. The tests hit state-dependent REST endpoints where each virtual user presents a session-specific token, and the payloads include timestamps that must be fresh on every iteration.

My understanding is that before 3.10, the HTTP protocol cache was enabled by default, so virtual users could reuse cached responses across iterations unless disableCaching(true) was set on the httpProtocol. From 3.10 onward the default flipped, so caching is disabled unless explicitly enabled. That transition leaves me unsure about the correct posture for simulations that never set either flag and were implicitly relying on — or accidentally affected by — the old default.

Specifically, I'd like clarity on three points:

• For a simulation upgraded from 3.9 to 3.10 with no explicit caching configuration, is explicitly setting disableCaching(true) still recommended as a defensive measure, or is it now redundant?
• Is there any documented mechanism (log output, warning, or assertion) to detect at runtime that a cached response was served instead of a fresh one, so stale results can be caught rather than silently accepted?
• When caching is intentionally enabled for static resources, what is the documented scope of the cache — per virtual user, per iteration, or shared across the scenario?