Two things about how https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#dom-createimagebitmap describes how an { imageOrientation } options object influences the image data it gets.

First, I find it odd that the createImageBitmap steps say "flipY" overrides the image's inherent orientation, instead of augmenting it with an additional vertical flip. Especially with other ~recent changes that treat correctly re-oriented images as the norm, and un-reoriented (e.g. using image-orientation: none) as being different from the norm. My guess (though I'm not sure) is that this imageOrientation option for createImageBitmap exists to make it easier to get image data into WebGL textures in the right orientation. If so, and if given an image with say a 90 degree EXIF orientation, it seems like it would better meet that goal by applying the vertical flip after applying the 90 degree rotation to correctly orient the image.

Second, it's not clear from the spec whether image-orientation: none on an <img> element passed to createImageBitmap should influence its result. We have some WPTs like html/canvas/element/manual/drawing-images-to-the-canvas/image-orientation/drawImage-from-element-swap-width-height.tentative.html, which tests that CanvasRenderingContext2D.drawImage() does take note of the property (and I think I may have asked @schenney-chromium to mark it as tentative because drawImage() also doesn't say anything about image-orientation), but from a very quick look I can't see a similar test for createImageBitmap.