Correct V47 picture.datatype alpha PNG contract for subclass datatypes?

I am implementing a picture.datatype subclass for AmigaOS 3.2.x, used for JPEG/PNG decoding. Specifically, this is for the ZZ9000 card, which has an ARM daughterboard, to which I'm off-loading some operations. I have written some standalone tools that work already, but I thought writing some Datatypes for common formats would be useful as well.
Since this is the first time I'm attempting this, I'm not sure if I'm doing something wrong. I couldn't find much documentation on the subject so far, so I thought I'd ask here.

My assumptions are based on:
- AmigaOS 3.2 NDK headers/autodocs, especially datatypes/pictureclass.h and datatypes/datatypesclass.h
- the AmigaOS 3.2.3/V47 picture.datatype behavior observed on real hardware
- comparisons against WarpPNG datatype behavior
- AROS datatype source examples for JPEG/PNG as reference patterns, while understanding AROS is not authoritative for OS3.2

Opaque PNG/JPEG works. Transparent PNGs are the problem, especially in IBrowse/MultiView. I tried several approaches and would appreciate guidance on the correct OS3.2/V47 picture.datatype contract.

Current stable path:
- subclass of picture.datatype
- PMODE_V43
- writes decoded pixels using PDTM_WRITEPIXELARRAY
- for alpha PNGs, if I ignore alpha and write PBPAFMT_RGB, it does not crash, but transparency is lost

Failed/problematic paths included:
- BMHD depth 32 + bmh_Masking = mskHasAlpha + PDTA_AlphaChannel TRUE
- writing PBPAFMT_RGBA / PBPAFMT_ARGB
- publishing a mask/transparent bitmap style result
These either crashed clients or produced incorrect results.
- BMHD: width/height/depth 8/masking 0/transparent 0 match
- PDTA_SourceMode = PMODE_V43 matches
- PDTA_DestMode = PMODE_V42 matches
- PDTA_NumColors = 16 matches
- PDTA_AlphaChannel = FALSE matches
- PDTA_BitMap/PDTA_ClassBitMap/PDTA_DestBitMap/PDTA_MaskPlane are all NULL before layout
- DTA_Methods lists PDTM_WRITEPIXELARRAY, PDTM_READPIXELARRAY, PDTM_SCALE, but not PDTM_OBTAINPIXELARRAY
- V47 direct buffer attempts using PDTA_ObtainPixelBuffer/PDTM_OBTAINPIXELARRAY also did not give me a working transparent PNG path. RGB-style direct writes were possible in some tests, but RGBA/ARGB alpha behavior was unclear and client compatibility was poor.

However, PDTM_READPIXELARRAY before layout differs:
- WarpPNG returns RGB for fully transparent pixels matted to the system background color, with alpha reads returning alpha=0
- my datatype returns the hidden source RGB from the PNG, with alpha ignored in the compatibility path

The V47 direct-buffer questions come from the NDK definitions for:
- PDTA_ObtainPixelBuffer
- PDTM_OBTAINPIXELARRAY
- struct pdtObtainPixelArray
- struct pdtBlitPixelArray
- PBPAFMT_RGB/RGBA/ARGB/LUT8/GREY8

I may be misreading the intended direction of these APIs: whether they are for subclass datatypes writing into picture.datatype storage, for applications reading/writing picture objects, or both. Clarification from someone familiar with OS3 picture.datatype would help.

Questions:
1. For an OS3.2 picture.datatype subclass, what is the correct way to expose true PNG alpha to clients?
2. Should a subclass set bmh_Masking = mskHasAlpha and PDTA_AlphaChannel TRUE, or is that not safe/expected on OS3?
3. Is PBPAFMT_RGBA/ARGB via PDTM_WRITEPIXELARRAY supported for subclass input, or should alpha PNGs be handled another way?
4. Does picture.datatype support transparent compositing for browser clients, or must the datatype precompose to RGB?
5. If precomposition is required, how can this work for browsers where the page background is not the Workbench/system background?
6. Is PDTM_READPIXELARRAY before layout expected to return source pixels, remapped pixels, or background-matted pixels?
7. Are PDTA_Screen and PDTA_Remap required from the application/client for alpha/remap behavior to work correctly?
8. Is there any known issue with IBrowse or MultiView requesting V47 picture attrs/methods that subclasses must handle specially?

Any guidance or small reference pattern for transparent PNG support in an OS3 picture.datatype subclass would be very helpful.

I also experimented with V47 direct pixel buffer support:

- PDTA_ObtainPixelBuffer tag
- PDTM_OBTAINPIXELARRAY method
- struct pdtObtainPixelArray / struct pdtBlitPixelArray
- requested PBPAFMT_RGB, PBPAFMT_RGBA, PBPAFMT_ARGB, GREY8/LUT8 variants

Questions about that path:
9. Is PDTA_ObtainPixelBuffer/PDTM_OBTAINPIXELARRAY intended for subclass datatypes to obtain a writable picture.datatype backing buffer during OM_NEW/decode?
10. If a subclass obtains a direct buffer, is it valid to write into pbpa_PixelData directly and skip PDTM_WRITEPIXELARRAY entirely?
11. What attrs must be set before requesting it? I used PDTA_SourceMode=PMODE_V43, DTA_NominalHoriz, DTA_NominalVert, and PDTA_SubClassRendersAll.
12. Is RGBA/ARGB direct-buffer alpha actually supported in OS3.2 picture.datatype, or only RGB/LUT/greyscale?
13. Are there lifetime rules for the returned pbpa_PixelData, especially after SetDTAttrs, layout, remap, or DisposeDTObject?
14. Should a subclass call PDTM_OBTAINPIXELARRAY on the superclass with DoSuperMethodA, or on the object with DoMethodA?
15. If direct buffer support is not reliable for OS3 clients like IBrowse/MultiView, is PDTM_WRITEPIXELARRAY the recommended path instead?