The problem is a 301 redirect with:

http://www.w3.org/1999/xhtml

wget http://www.w3.org/1999/xhtml

--2022-12-09 15:20:18-- http://www.w3.org/1999/xhtml
Resolving www.w3.org (www.w3.org)... 104.18.23.19, 104.18.22.19, 2606:4700::6812:1613, ...
Connecting to www.w3.org (www.w3.org)|104.18.23.19|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.w3.org/1999/xhtml [following]
--2022-12-09 15:20:18-- https://www.w3.org/1999/xhtml
Connecting to www.w3.org (www.w3.org)|104.18.23.19|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.w3.org/1999/xhtml/ [following]
--2022-12-09 15:20:18-- https://www.w3.org/1999/xhtml/
Reusing existing connection to www.w3.org:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘xhtml’

The default sitemap template for sitemap.xml in Hugo contain

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/1999/xhtml">

Changing it just to

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/TR/xhtml11/xhtml11_schema.html">

adding the way of displaying sitemaps in subfolders exactly like the root one.

As mentioned here:
https://stackoverflow.com/questions/16798979/xsd-for-sitemap-with-hreflang

but then Google Search Console will start complaining about Incorrect namespace.

Firstly it's better to think if we need to fix that. I don't think we need it. Google search engines are reading these files, not users. I understand that users may want to preview that, but overall I am sticking with defaults.

@idarek The PR I submitted (#10516) fixes this trivial redirect problem, and adheres to both the sitemap protocol and Google's recommendations for multilingual sites.

Works locally. Fails in production (Cloudflare Pages).

Work on both on my end. I copied templates from Hugo GitHub repo and created in my layout all works fine now.

I also commented on the changeset:

A XML namespace is usually not meant for browsing. The expected value should be using a http:// prefix as mentioned in the docs.

Switching to https:// may result in unexpected behaviour (eg. tools that consume those XML files may have trouble with this).

@McShelby

I agree. Given that the host + path is unique, I incorrectly assumed that the protocol was irrelevant. Looking at the spec, it is indeed a full string comparison.

John Mueller of Google, in this thread, states:

Yes, it's essentially an identifier. Google accepts both, since people tend to use them interchangeably nowadays.

But just because Google does, it does not mean that everyone else does. I will revert 3fd0b78.

In the future, please open a new issue instead of commenting on a commit or a closed issue. Thanks.