Thank you for continuing to work on this.
It is possible for graphics->hdc to not be NULL when graphics->image is a Bitmap object. You can see in GdipCreateBitmapFromScan0 that we create an HBITMAP object for some pixel formats, and GdipGetImageGraphicsContext will create an HDC if an HBITMAP exists. This is currently necessary because our non-gdi32 drawing code is incomplete, but when that is fixed we will no longer create HBITMAP or HDC objects for Bitmap objects.
We should still leave alpha_blend_pixels_hrgn alone because we control these HDC objects and will never change their window origin.
Your approach looks good, but I have some issues with the tests.
I would prefer that you use the expect() macro when comparing integers in tests.
If you don't expect a function (in this case GetDIBits, in patch 2) to fail when running a test, use ok() to check that it succeeded. It's OK if the test will crash when the ok() check fails.
If GetDIBits really does fail sometimes, we need to understand why that happens and document it in the test.
When writing comments about this, make sure you specify that you are talking about gdi32 device coordinates, which are different from gdiplus device coordinates.
+ status = GdipSetClipRectI(graphics, rect.left+width/2, rect.top+height/2, + rect.right, rect.bottom, CombineModeReplace);
This looks wrong to me. GdipSetClipRectI takes a width and height, not right and bottom.