I will have to defer to Slawek on the policy checking, but think the behavior might be different on master due to the code maybe being different? Locally I see the OVN metadata port creation fail, triggering an  exception:

ERROR neutron.plugins.ml2.managers Traceback (most recent call last):
ERROR neutron.plugins.ml2.managers   File "/usr/local/lib/python3.10/dist-packages/neutron_lib/plugins/utils.py", line 306, in _fixup_res_dict
ERROR neutron.plugins.ml2.managers     attr_ops.populate_project_id(context, res_dict, True)
ERROR neutron.plugins.ml2.managers   File "/usr/local/lib/python3.10/dist-packages/neutron_lib/api/attributes.py", line 257, in populate_project_id
ERROR neutron.plugins.ml2.managers     _validate_privileges(context, res_dict)
ERROR neutron.plugins.ml2.managers   File "/usr/local/lib/python3.10/dist-packages/neutron_lib/api/attributes.py", line 32, in _validate_privileges
ERROR neutron.plugins.ml2.managers     raise exc.HTTPBadRequest(msg)
ERROR neutron.plugins.ml2.managers webob.exc.HTTPBadRequest: Specifying 'project_id' or 'tenant_id' other than the authenticated project in request requires admin or advsvc privileges
ERROR neutron.plugins.ml2.managers 
ERROR neutron.plugins.ml2.managers The above exception was the direct cause of the following exception:
ERROR neutron.plugins.ml2.managers 
ERROR neutron.plugins.ml2.managers Traceback (most recent call last):
ERROR neutron.plugins.ml2.managers   File "/opt/stack/neutron/neutron/plugins/ml2/managers.py", line 497, in _call_on_drivers
ERROR neutron.plugins.ml2.managers     getattr(driver.obj, method_name)(context)
ERROR neutron.plugins.ml2.managers   File "/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py", line 633, in create_subnet_postcommit
ERROR neutron.plugins.ml2.managers     self._ovn_client.create_subnet(context.plugin_context,
ERROR neutron.plugins.ml2.managers   File "/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py", line 2197, in create_subnet
ERROR neutron.plugins.ml2.managers     mport_updated = self.update_metadata_port(
ERROR neutron.plugins.ml2.managers   File "/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py", line 2363, in update_metadata_port
ERROR neutron.plugins.ml2.managers     metadata_port = self.create_metadata_port(context, network)
ERROR neutron.plugins.ml2.managers   File "/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py", line 2331, in create_metadata_port
ERROR neutron.plugins.ml2.managers     return p_utils.create_port(self._plugin, context, port)
ERROR neutron.plugins.ml2.managers   File "/usr/local/lib/python3.10/dist-packages/neutron_lib/plugins/utils.py", line 335, in create_port
ERROR neutron.plugins.ml2.managers     port_data = _fixup_res_dict(context, port_apidef.COLLECTION_NAME,
ERROR neutron.plugins.ml2.managers   File "/usr/local/lib/python3.10/dist-packages/neutron_lib/plugins/utils.py", line 312, in _fixup_res_dict
ERROR neutron.plugins.ml2.managers     raise ValueError(e.detail) from e
ERROR neutron.plugins.ml2.managers ValueError: Specifying 'project_id' or 'tenant_id' other than the authenticated project in request requires admin or advsvc privileges

I would have thought you'd see the same since this change was backported, but don't know.

Either way, we'll have to discuss what the correct answer is since it seemed like the subnet creation actually succeeded just to fail in a post-creation task.

At first guess I'm not sure what my opinion is. Obviously on a shared network we need to allow users to create things like ports (to boot a VM), and although subnets are something that could have other impacts (like routes, etc.), it doesn't seem like we have not allowed this in the past.