is it intuitive for the developer implementing liveValue for their dependency that despite being a calculated var it won't be recalculated because of the cache? At least it wasn't intuitive for me.

The cache was added at a later date because people didn't find the uncached behavior intuitive. Many times users will introduce computed static vars that require some configuration code, and this would subtly break their applications. Because dependencies are basically treated as singletons in most code bases, and only commonly overridden in tests, a lack of cache made most of these dependencies stateless by default. The one gotcha is the one you encountered, where an inline dependency that is resolved outside the default scope will be cached into the default scope. We're not sure if there are ways to address this, but are open to suggestions.

wouldn't be beneficial for the swift-dependencies library to resolve such cases in an expected way (invalidate related dependencies in the cache) to allow for their recalculation?

The main issue here is that stateful dependencies may lose their state (e.g. a logged-in API client may lose its token), but if you have a suggested way to achieving this we're open to discussing a PR!

If cache of dependencies alters the behaviour (depending on which call comes first - you'll get different results) and disabling that cache fixes the issue - isn't it a sign that smth. is wrong with the cache implementation?

We're open to any improvements here if you have any suggestions. The cache is quite simple, but the complication is how task locals propagate.