Works for me. See (initial run without cache and then a subsequent run). Drilling down to the specific steps where the action is used see this job from the initial run and the this job from the subsequent run: in particular steps Fetch cargo-deb from cache, Install cargo-deb if needed and Force cache save the latter showing the saving of the cache much earlier than was previously possible, and more importantly saving it before later steps that may fail the job while we still want the results of costly setup steps to be saved to the cache regardless of subsequent failure.

One strange thing is that all of the cache save steps I can see result in Failed to save due to the cache key already being in use, but as I manually cleared the caches before the run using gh actions-cache delete and that a subsequent run, and even other parallel jobs in the same run, are able to fetch the cache key, I can't see any actions/cache/save or actions/cache post step that actually saved the key in the cache...

@kotewar: For some context, I'm using actions/cache/save to address NLnetLabs/ploutos#47.

Just writing here to say thank you for already integrating the feedback from #1020 (comment) (unconditionally set cache-matched-key output on successful restore).