Sorry to be late on this, but just to let you know if that matters to you:

allow caching responses with status codes from HEURISTICALLY_CACHEABLE_STATUS_CODES array when they have explicit cache directives

Is still more restrictive than the RFC.

Storing Responses in Caches
A cache MUST NOT store a response to a request unless:
...

• the response status code is final (see Section 15 of [HTTP]);
• if the response status code is 206 or 304, or the must-understand cache directive (see Section 5.2.2.3) is present: the cache understands the response status code;
  ...
• the response contains at least one of the following:
  • a public response directive (see Section 5.2.2.9);
  • a private response directive, if the cache is not shared (see Section 5.2.2.7);
  • an Expires header field (see Section 5.3);
  • a max-age response directive (see Section 5.2.2.1);
  • if the cache is shared: an s-maxage response directive (see Section 5.2.2.10);
  • a cache extension that allows it to be cached (see Section 5.2.3); or
  • a status code that is defined as heuristically cacheable (see Section 4.2.2).

The status code being heuristically cacheable is not required for caching, unless none of the previous alternatives are met. Which means, a response containing a cache directive may be cached event if its status code is not heuristically cacheable.

Other paragraphs add further restrictions but also clarify this.

5.2.2.9. public
The public response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the constraints defined in Section 3. In other words, public explicitly marks the response as cacheable. For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (Section 3.5).

Note that it is unnecessary to add the public directive to a response that is already cacheable according to Section 3.

If a response with the public directive has no explicit freshness information, it is heuristically cacheable (Section 4.2.2).

According to the last sentence the heuristically cacheable test has to be done in the case no expiry is provided in the cache directive. Nothing mandates the response to be heuristically cacheable for explicitly cacheable responses (with expiry for the shared cache case, the private one does not have that constraint of having an explicit expiry).

For example it means 302 and 307 are cacheable too, if there is an explicit caching directive.

But implementing the RFC in order to cache in all circumstances allowed by the RFC looks like it would requires a convoluted logic, which seems undesirable to me. Especially implementing heuristic caching (caching of responses without explicit caching directive) looks cumbersome.

Anyway, your implementation is compliant and aligned with the RFC, just not as permissive as the RFC. It does not mandate caching, but states instead "may cache".

So, why not leaving it as it is currently.

Edit: I think I have miss-understood the sentence:

If a response with the public directive has no explicit freshness information, it is heuristically cacheable (Section 4.2.2).

I have read it as meaning it should have an heuristically cacheable status code. But I now think it just means an heuristic cache duration can be applied to cache response with public directive but no expiry.

@fredericDelaporte further PRs that improve things are always very welcome! If you want to open a tracking issue.. go ahead!