In openfl next (but not openfl legacy I think), all pixels in a BitmapData object are stored as premultiplied color values. This is generally a good idea, as it can speed up and ease most of general color composition operations (like the overlapp of two bitmaps with some transparency) and save some memory. But this can also create some issues in the case of smothing/rescaling with transparent pixels (complete transparent pixels are all stored as 0 wich mean it would be considered as a black pixel color in smothing operations for example) but also complex multiple pixels operations (like lights effects in 3D where keeping all the possible information of a color along the way might import to get a consistent color at the end (premultiplied colors can lead to a significant information loss)).
So I am wondering if it could be possible to have a “BitmapDataAlpha” class that extend the regular Bitmapdata but will store RGBA colors on 4 channels (rather than 3 actually for usual BitmapData) for people that might need this precision.
Or maybe a flag on the BitmapData constructor that could allow to activate/deactivate the premultiplied alpha storage mode…
I don’t know if it would be a hard work to add this functionnality but I think having the possibility of using “high precision” bitmapdata might be usefull in some cases 
(So it might be some improvement to consider if it is not too much work)
Flash Player is a bit curious. If you create a new BitmapData, it preserves the color you set initially, without the data loss connected to premultiplied alpha, but if you begin modifying pixels, you will find data loss consistent with storing as premultiplied data. I’m not 100% sure of the exact method being used.
1.) Using premultiplied data brings to Flash Player behavior in most tests
2.) BGRA + premultiplied alpha is the format of Cairo surfaces, using this in OpenFL enables a huge performance boost, as we can go in and out of Cairo without additional conversion
Strictly speaking, Lime Image supports premultiplied true/false (and different color orders), so perhaps work could happen there, before turning it into BitmapData for use with OpenFL?