In my perspective it does not make sense to create another JSON-SCHEMA based form generator if something like https://github.com/json-editor/json-editor already exists, even integrated into (Semantic)MediaWIki (https://github.com/OpenSemanticLab, see also https://phabricator.wikimedia.org/T324933).
For visual consistency a OOUI theme (https://github.com/json-editor/json-editor?tab=readme-ov-file#css-integration) should be considered.
For students it would also be easier to create new custom editors (https://github.com/json-editor/json-editor?tab=readme-ov-file#custom-editor-interfaces), e.g. for Geolocation/Maps or Tree Views, than digging into the fundamentals of JSON-SCHEMA.
Also, a JSON-SCHEMA schema editor with full support of the JSON-SCHEMA (meta)schema quickly escalates to something that is not useable for average users (see https://json-editor.github.io/json-editor/meta-schema.html). In OpenSemanticLab we use a simplified metaschema and templating for this usecase.

Certainly, that page on mediawiki.org wouldn't be updated until the patch is actually merged :)

Makes sense... =D

Not sure how to update the documentation - directly in API:Siteinfo?

Isn't that just because the scripts for mysql / mariadb and sql-lite use

INSERT (OR) IGNORE

while postgres does NOT use the equivalent

ON CONFLICT DO NOTHING`

? (see https://github.com/search?q=repo%3Awikimedia%2Fmediawiki%20filearchive-fa_major_mime-patch-fa_major_mime-chemical.sql&type=code)

In T324910#8485601, @Tgr wrote:

In T324910#8484979, @Krinkle wrote:

It seems though that the relevant API already exists today. I don't know what upcoming feature or use case prompted this task, but that means it isn't blocked on a new API as it already exists.

As long as RawAction isn't deprecated (whatever that would mean for an action), it makes sense to aim for feature parity IMO.

@Simontaurus would the action API work for your use case? [...] The content is wrapped in JSON (there is no way to get just the raw content string); other than that I don't think there's any disadvantage IMO. [...]

The usecase at this point is to place a machine readable document behind an URI. Specifically, it's about json-schema, which are referenced both absolutely and mutually among themselves.
(see also json-schema.org and T324933 )
In this way, for example, a category can specify the schema for structured data that must be followed by pages in that category.

In T324910#8458712, @Tgr wrote:

Would you like to submit a core patch?

On stackoverflow there are some suggestions for a more robust solution for this limitation of XPath1,
e. g. using regex or iterate over all nodes an check for default namespace declarations.
https://stackoverflow.com/questions/1245902/remove-namespace-from-xml-using-php

Thanks for providing the patch. Problem fixed: Named subobjects now create link texts from display title as expected ("DisplayTitle" in the given example)