First, two repros:

[fixed-pos] http://output.jsbin.com/livamap/quiet
[nested] http://output.jsbin.com/vowolom/quiet

Steps:
1. click the button
2. try to scroll the inner scroller by mouse wheel or touch gesture

Expected: inner scroller scrolls
Actual: outer scroller scrolls

These require low DPI or --disable-prefer-compositing-to-lcd-text.  They repro with and without RLS, and are not regressions.  High DPI repros are also possible with border-radius.

Background:

We store a "non-fast scroll region" on the document's scrolling contents layer (or PLC::scroll_layer_ before RLS) corresponding to the locations of all scrollers inside the document that don't use composited scrolling.

If the compositor thread sees scroll input in this region, it passes it on to the main thread.

The non-fast scroll region is updated when scrollers are added, removed, or resized, but it is not updated when any scroll operation (LocalFrameView, root PLSA, or non-root PLSA) occurs.

Usually that's ok because the non-fast scroll region is in document-content-space coordinates (see https://www.chromium.org/developers/design-documents/blink-coordinate-spaces, and note that this is being fixed for RLS in  issue 816660 ).

But in [fixed-pos], the scroller is position: fixed, so its location in document-content-space changes when the document scrolls.  It is also "semi-composited": it is promoted due to its composited descendant, but it does not have scrolling layers.  (If it were not promoted at all, we would set MainThreadScrollingReason::kHasNonLayerViewportConstrainedObjects on the document, making the non-fast scroll region irrelevant.)

In [nested], the outer non-root scroller is (fully) composited due to its opaque background, but the inner scroller is not.  The location of the inner scroller changes when outer is scrolled.

A naive fix would simply recompute the non-fast scroll region after every scroll, but this may have negative performance implications.