Sorry, to be clear on the last statement: "unfriendly" was said about the background-attachment-fixed CSS property, not the fixed div with absolute background :) I have to use background-attachment-fixed property as a temporary "patch". But hope you'll help to get it back like it was in older Chrome versions.

I tested your test URL using Chrome 50, 54 and 58 on Windows and macOS, also on Chrome 27 and 32 on macOS and on some Android 6 and 4.4 Chrome versions. All of them did not show any difference.

I do see the difference in Safari, but this is not a Chrome regression so far (but the non-test URL you posted to the discussion group did show a difference between Chrome versions, so something else is going on there that is not in the test URL).

Your test URL works in Safari 6.1 - 10.1 and does not work in any Chrome version that I tested, nor does it work in any other browser.

Most of the chances are that you rely on a nonstandard WebKit behavior that was fixed in Chrome and is not yet fixed in Safari. In that case, I would not count on getting a fix for this (instead, Safari might also regress for you at some point).

On Android, I do sometimes see a brief flash of the content "below" (in the z-index sense), which might be a paint or compositing issue.

(All of the tests were run using BrowserStack)

I added Hotlist-Interop only because at least one browser shows the expected output (Safari).

I will let the teams examine and decide.
(Sorry for all of the components, I am not sure what is the most relevant component here because there are a few issues)

Original discussion -
https://groups.google.com/a/chromium.org/d/msg/chromium-discuss/gNt1hO71Uu4/voRG1t_0CAAJ

You have mentioned a "nonstandard WebKit behavior that was fixed in Chrome and is not yet fixed in Safari" which seems to be true since originally fixed divs are meant to be positioned to viewport, not their parents (as it always was in Firefox and IE). Actually this behavior continued in Chrome for more than a year. Then it suddenly changed. 

The thing is that if you compare the FPS and speed of rendering "fixed div" and "normal div with background-attachment-fixed", then you'll see noticable difference between them. Especially if you have many text etc.

When I tested my website on different devices about a year ago, the "fixed divs" trick showed nearly a twice FPS increase on weaker machines (by weak machines I mean i3 and i5 computers with built-in graphics). 

Actually the choppy scrolling was solved by adding fixed divs inside their parents instead of using a fixed background to those parent divs. 

So, even if it was a WebKit temporary "bug", then maybe get it back? Even though it expands the bounds of original CSS3 specification, it is not that type of "bug" that causes problems. Actually it helps to double FPS. 

#5 - if this violates a CSS specification or if it is not an interoperable behavior, most of the changes are that it will not be re-added, regardless of the speed benefits. There are probably things you can do to get better performance, see https://developers.google.com/web/updates/2016/12/performant-parallaxing for details (I have not verified that article, I just remembered they discussed it at some point).

I wouldn't call it a violation. Perhaps, there was just some flexibility in terms of interpreting fixed divs relation to viewport or parent div. Anyway, if this feature is not going to be re-added in Chromium and considered an interoperable behavior, then we'll hope they keep it for Safari at least.

#7 - I am pretty sure it is a violation. Flexible specifications lead to unpredictable behavior, which is why recent specifications tend to specify everything. If they have not specified something and a behavior difference is spotted, this usually leads to a specification change.
You want all of the browsers to behave the same (unless you really want to solve your problems in multiple ways, in order to challenge yourself ;)).

All of the browsers are on a trend to improve interoperability, so I would not count on Safari keeping this behavior for too long. Interoperability is on a long journey towards an all-or-nothing approach.

Safari has filed bugs for improper clipping fixed positioned elements -
https://bugs.webkit.org/show_bug.cgi?id=160886
https://bugs.webkit.org/show_bug.cgi?id=160953

In particular, see comment https://bugs.webkit.org/show_bug.cgi?id=160953#c2 by an Apple employee.

I strongly recommend that you -
1. Write interoperable code according to the standard, that works across browsers. Code that only works in some browsers lead to an undesirable lock-in and can break at any point.
2. Find other ways of implementing your effect, that work across browsers.
(3. Use HTTPS. :))

Thanks for the report simpleman14031988 and the detailed analysis phistuck!
Closing as per comment 8.