Just to clear things up since i think stuffs had been misunderstood by a lot of people:

What will this bounty achieve:
- Menu/Menu Widgets working in a better way
- Post processing shaders support

What this bounty won't achieve (and won't help development for):
- Hardware acceleration in cores

Even when this bounty will be collected, progresses for hw accelearation in cores would be the same than now. Gonna explain why:

RetroArch workflow can be divided in two macrosections: frontend (RetroArch itself) and backend (cores).

Frontend can expose to cores an hardware context which basically is composed of a context to use GPU and a function to grab addresses for the functions exposed to that API (i'm simplifing stuffs since it's way more complex than this). Cores, after getting those functions, can use the related API to get advantage of the GPU and draw everything on a framebuffer. This framebuffer, after a frame is fully rendered is returned to the frontend which then performs a last rendering stage where it applies post-processing shaders as well as drawing on top of it menu/layout/OSD warnings etc.
So, why adding a new HW_CONTEXT (eg. HW_CONTEXT_GXM or HW_CONTEXT_VITA2D) won't make any differences in terms of cores being able to access GPU?
If you well understood my little explanation, you probably got the point: basically EVERY core would need to be COMPLETELY rewrote from the groundup to use the new exposed API instead of GL/Vulkan/D3D. This summarize in basically having to port the whole emulator/game engine the core is to a brand new API and this work won't be done by anyone (it would actually imho be simpler to just port an emulator to GXM in a standalone way instead of having to rely on libretro since libretro itself adds some limitations at least on the Vita build such as, for example, the unability to increase main thread stack size). I've recently proposed something that could actually indeed make Vita build (as well as 3DS and PSP builds) get hardware acceleration in (at least some) cores relatively easily.
This will need basically to add still a new hw context based on the already implemented "gl1" video driver. gl1 video driver atm has no hw context capability cause of how hw context itself works for GL API but things can be sorted out to work with GL1.x too. Once we have a HW_CONTEXT_OPENGL1, we can easily drop a new renderer in vita build that uses vitaGL and fully implements said hardware context. The advantages to have an OPENGL1 hw context instead of a GXM one are multiples:
- There are tons of documentation and samples on how to use GL1 compared to GXM.
- There aree tons of experienced developers with GL1 compared to GXM.
but MOST IMPORTANTLY:
- Several cores actually using HW_CONTEXT_OPENGL can be easily adapted to use only GL1.X features making them easily portable.
That's the referenced opened issue for this implementation if anyone's interested on ETA/who's working on it/contributing via bounties/whatever else came in your minds: https://github.com/libretro/RetroArch/issues/9603