I believe that The 'NET ERR' part should be under 'Advanced' and that there should be an option/flag to automatically reveal the 'Advanced' part by default.

For this specific issue, I fall back to the simple phrase:
"You can't fix the stupid".

If users ignore the errors then they will compromise their privacy/security just like those warning pages already state.

Hmm. The user clicked through both interstitials, and the current page already has a downgraded lock. It seems to me like the current behavior would be the expected behavior?

Re #1: That comment seems to be off-topic, it isn't related to this thread.

Re #2: I didn't explain this very well in the description (I agree that the straightforward case I described is more-or-less okay as it works now), but my concern is that the current behavior is somewhat complicated and has a lot of gnarly edge cases, many of which are almost certainly implemented buggily.

Some examples:
- If https://good-ssl.com loads over good HTTPS and loads a script from https://expired.badssl.com, I think ideally we should treat that like active mixed content (block it by default)... but right now we automatically allow it (albeit with a red slashy lock icon). If we go ahead and do this, then I think we should always block active broken-HTTPS subresources inside iframes in the same way that we always block active mixed content in iframes... a user clicking through a shield on https://foo.com isn't going to realize that they're also allowing all origins that https://foo.com is framing to run active mixed content.
- The current code has a check so that we don't report "duplicate" certificate errors up to the browser process. (The browser doesn't need to be notified about every same-origin subresource on https://expired.badssl.com loaded with the same certificate errors as the main resource.) This check is sort of clunky as is and it would be very tricky to implement correctly for OOPIFs. I think in the current implementation we do this check correctly for most cases, but for example if you have https://expired.badssl.com embedding https://foo.com (OOP) which loads a subresource from https://expired.badssl.com, we don't correctly filter that as a duplicate certificate error. I'm pretty sure this doesn't end up mattering for Chrome, but I think it might get Opera's security UI confused.
- When a site runs a mixed (or broken https) script, we mark that origin as nonsecure for the entire lifetime of the renderer process. But our implementation isn't really consistent about that when it comes to nested iframes. For example, if https://expired.badssl.com embeds https://foo.com (good HTTPS) which loads a broken-https script, I think we should mark both expired.badssl.com and foo.com as slashy, but right now foo.com maintains its green lock (IIRC).

Ah yes, I agree that the first case is problematic and would support blocking it by default.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

One ramification of the current behavior is described in issue 620500 (RVG). Are there any plans to work on this?

I haven't had a chance to work on this, sorry. I'll take a look at issue 620500 though.