I found this issue type suites most to my "finding" according to the FAQ.

<b>Chrome Version: <Copy from: 'about:version'></b>
OS: -
Crash ID: -

URL (if applicable) where crash occurred:
none

Can you reproduce this crash?
I think I could if I would spend a lot of time on it. But it is more like a theory.

What steps will reproduce this crash (or if it's not reproducible,
what were you doing just before the crash)?
(1) Visiting a site which presenting a mocked certificate for a domain with an HPKP header (and possibly with an HSTS), so the attacker is an MITM attacker.
(2) The attacked SSL applying site will not be accessible until the malicious header expires over SSL. (If the header accepted and remains "cached")

If the original site was not loaded yet, or HPKP header of the site expired or did not applied at all, the site could be "inverse DOS"(?)-ed by the attacker with the header. (I did not found any information on how to elliminate this risk in developer guide lines)

Naturally the DOS persists after the visitor left the malicious network.

I think with making calls for different domains (mocked by the attacker) one site could deny different sites from usage a user visiting a single page (but malicious) willingly.

Maybe you are aware of this (theoretical) attack vector.
It is more like the bug of the HPKP secutiry header itself, so I think you won't need to fix this on Chromium in the first place, but please consider to contribute to change the header if you are willing to, and find the report serious enough.

Maybe there should be a possibility to lock pinning for a domain if I don't want to support it on the near future, but I suggest to find an other solution because this is risky on it's own.

Your dev guide line does not mention this vector on
https://developers.google.com/web/updates/2015/09/HPKP-reporting-with-chrome-46

Best reguards,
Richárd

*Please note that issues filed with no information filled in above
will be marked as WontFix*