The difference between Chrome 67 and 69 reproduces for me on Linux(/NVIDIA) as well.

That said, if 67 is wrong and 69 is correct, something must have fixed this recently?

Yes, you're right. But, unfortunately I don't know when something that fixes the problem migrates from Canary to Chrome.
I hope the issue attracts more attention to the situation.

https://www.chromestatus.com/features/schedule

Chrome 69 is scheduled for Sep 4.

If the fix is in Chrome 68 (beta channel), you'll get it around Jul 24.

An automated pixel test was added for WebGL's premultipliedAlpha:false support in  Issue 599285 , and looking back through the log for https://cs.chromium.org/chromium/src/content/test/gpu/gpu_tests/pixel_expectations.py I don't see any suppressions being added or removed.

http://omahaproxy.appspot.com/ says that M67 was branched at r550428. Testing the two public builds around that branch point:

https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/550422/
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/550430/

both run the test correctly.

The most likely cause, unfortunately, is that a merge-back of a bug fix to M67 broke this behavior. Also unfortunately, there aren't trybots for the official builds yet, although a lot of progress has been made in this area in Issue 663061 and related bugs. Once there are, then merge-backs should be able to go through the commit queue, and breakage of functionality like this should be avoided. Linking to Issue 663061 to make it clear that such trybots will prevent regressions like this one.

Apologies for this breakage, but on our team right now there is nothing we can do. If you can please test Chrome's early access builds (beta, dev) and file bugs early, we can catch issues like this before they reach Chrome Stable.