loadImage(...) and createGraphics(..., P2D) have different y-coordinates

Most appropriate sub-area of Processing 4?

OpenGL

Processing version

4.4.4

Operating system

MacOSX

Steps to reproduce this

PShader texCoordShader;
PGraphics pgP2D, pgDefault;

void setup() {
  size(800, 400, P2D);
  
  String fragShader = 
    "#ifdef GL_ES\n" +
    "precision mediump float;\n" +
    "#endif\n" +
    "varying vec4 vertTexCoord;\n" +
    "void main() {\n" +
    "  gl_FragColor = vec4(vertTexCoord.st, 0.0, 1.0);\n" +
    "}";


  saveStrings("frag.glsl", split(fragShader, "\n"));
  texCoordShader = loadShader("frag.glsl");//, "vert.glsl");

  pgP2D = createGraphics(400, 400, P2D);
  pgDefault = createGraphics(400, 400); // Default JAVA2D renderer

  pgP2D.beginDraw();
  pgP2D.endDraw();

  pgDefault.beginDraw();
  pgDefault.endDraw();
}

void draw() {
  background(0);
  shader(texCoordShader);
  image(pgP2D, 0, 0);
  image(pgDefault, 400, 0);
}

Additional context

I'm working on a keystone library that is using a shader.
Because a image has different coordinates then a graphics created with P2D I need to know what the user is giving.
Not only that, it complicates the shader math way more then I would like.

To give an example:

The difference between those is P2D and default renderer (both in a sketch that is P2D).
Notice that the text is correct in both cases!!!

This does not just apply for PGraphics, using loadImage is different as well (cause also baked by a BufferedImage).
Having a mix of both of them really complicate things.
Complaining is easy however. I will dig into seeing if I can find a solution.

Would you like to work on the issue?

Trying...

Reproduce the supplied sketch and compare the texture-coordinate behavior of loadImage(...) with createGraphics(..., P2D), including the BufferedImage path and shader output. Start from these entry points and PGraphics, then determine whether the coordinate convention can be made consistent; done means both image sources produce the same y-orientation under the shader.