I can't see any change with either M-58 or M-60 on Mac. I know that neither of those is the version you are reporting for, and it may be that the change is too subtle for me to see under my lighting and screen conditions.

Could you try Chrome Canary to see if the problem persists?

Layerization does change when switching flex/block display. That is the most likely cause of the change.

Yes, it happens in canary also. You can use color sampling tools to see the different color generated with/out the flex  

Thank you for providing more feedback. Adding requester "schenney@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Tested this issue on Mac 10.12.4 using latest Canary #60.0.3082.0, Unable to reproduce the issue, Could you please find the attached screen cast and let us know if any steps are missed from our end

Deleted: Apr 27 2017 2-31 PM.webm 1.3 MB

	Apr 27 2017 2-31 PM.webm 1.3 MB View Download

The change in text color is very subtle, I can see it in your attached cast. 
Please use 3rd party tool (like an eye dropper) to test the color, you will see different hex generated per click.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

In version 60.0.3091.0 (Official Build) canary (64-bit) on MacOs 10.12, I get a rgb color for the text of 9,130,182 regardless of the flex settings.

Are you sure you are sampling the color in a portion of the text that is wholly opaque, and not a part of the antialiased edges? Anti-aliasing may well differ according to block vs flex.

And are you on a retina display or other High DPI device?

The following screen shots where taken from Version 60.0.3093.0 (Official Build) canary (64-bit)

In Both images sampling the color from the middle of the letter gives 9,130,182 but the surrounding gives other color. So it may be that the antialiased edges have more weight here? and it does give the end user a totally different result...

I had to add the following styles in order to resolve the issue: 
 -webkit-filter: blur(0.000001px);
  filter: blur(0.000001px);

Deleted: Screen Shot 2017-05-09 at 09.37.12.png 18.2 KB

	Screen Shot 2017-05-09 at 09.37.12.png 18.2 KB View Download

Deleted: Screen Shot 2017-05-09 at 09.37.25.png 18.2 KB

	Screen Shot 2017-05-09 at 09.37.25.png 18.2 KB View Download

Thank you for providing more feedback. Adding requester "schenney@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thanks for the feedback. At least we know we're seeing the same thing.

I'll poke around a little more to understand what is changing (position, composited status, something else) in case we are doing the wrong thing.

The NextAction date has arrived: 2017-05-22

What is the status? It is still happening as of todays Canary and Official 

Yes, I've dug a little and indeed the color change is a result of a change in the composited status of the span with the transform. The next step would be to see why that composited status changes, as I would expect the span to get it's own composited layer regardless of flex/block given the translate on it. It is almost certainly due to layer squashing or some other internal compositing decision.

Interestingly, the initial status is composited for that translate span, but it is switched when the display is set to block.

I'm not going to dig further on this right now. Could you explain why this situation is important to your content so we can prioritize it correctly?

It is important because it's our brand color and flex is/will become a standard.
 
So displaying the right color set to the browser is a must IMHO.  
Please, do not reduce the priority as we are straggling with it and using filter:blur(0.000001px); in order to avoid this, which may hurt performance 

The compositing state changes in the example, because it changes the span to
no longer be inline. Transforms don't apply to inlines.

As for why the color changes, that is likely because of a rounding difference when blending
with another texture. To avoid such rounding, you need to provide an opaque background of the
element with the color you want to preserve.