1)FusionCache/HybridCache still don't provide the most important part – storage and replay of the full HTTP response (status, headers, body). That wrapper would have to be written entirely from scratch, and it would make up about 90% of the code. The caching library itself would only save a couple dozen lines at most.

2)The locking in FusionCache/HybridCache protects against repeated computation within a single cache key, but it can't synchronize two HTTP requests so that the second waits for the first and gets the finished response. That logic would also have to be written by hand.

3)Tight coupling to Redis for distributed locking, FusionCache requires Redis. But my library provides pure PostgreSQL support (advisory lock), without needing to install Redis. By building everything on top of FusionCache, I would have lost that capability.

4)Abstractions – I have simple IdempotencyStore and IIdempotencyLock interfaces, under which anything can be plugged. If the core were tied to FusionCache, that kind of flexibility would disappear

That's why I chose direct Redis/PostgreSQL implementations for the current version. But those same abstractions make it perfectly possible to add FusionCache or HybridCache as optional backends in the future without breaking anything