Cloudfront distribution bug with Managed-SimpleCORS response policy?

We have a problem with CloudFront and something that for us seems to be a bug. CloudFront is in our case inconsistently following the Managed SimpleCORS policy based on region. Our configuration is a distribution with an S3 origin, where the following policies are being used:

• Viewer protocol policy: Redirect HTTP to HTTPS
• Cache policy name: Managed-CachingOptimized
• Origin request policy Name: -
• Response headers policy name: Managed-SimpleCORS

Initially it works fine, also seems to work fine if we run an invalidation for a little while, but it has happened several times now that we see that over time, the CORS response is not correct depending on the geographical region the request is being sent from. This causes a CORS issue in e.g. Chrome. We have even tried creating a new CloudFront distribution from scratch, configuring the behaviour and origins, and end up with the same result.

The issue is verifiable using the following CURL request:

curl -i 'https://dist.mysite.com/fonts/mulish-v12-latin-700.woff2' \
  -H 'authority: dist.myworkout.com' \ 
  -H 'accept: /' \
  -H 'accept-language: en' \
  -H 'cache-control: no-cache' \
  -H 'origin: https://go.myworkout.com' \
  -H 'pragma: no-cache' \
  -H 'referer: https://go.myworkout.com/styles.fad176935017dfec.css' \
  -H 'sec-ch-ua: "Chromium";v="110", "Not A(Brand";v="24", "Google Chrome";v="110"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Windows"' \
  -H 'sec-fetch-dest: font' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-site' \
  -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36' \
  --compressed

yields this correct result from Norway (where the access-control headers ARE included):

HTTP/2 200 
content-type: font/woff2
content-length: 11164
access-control-allow-origin: *
access-control-allow-methods: GET
last-modified: Fri, 13 Jan 2023 20:03:47 GMT
x-amz-server-side-encryption: AES256
x-amz-version-id: vZw9469Ogk6XEvU5RIQmB288hzwQr6zG
accept-ranges: bytes
server: AmazonS3
date: Wed, 08 Feb 2023 19:52:10 GMT
etag: "d08677b723b410a78debca060c4d2ca2"
vary: Accept-Encoding
x-cache: Hit from cloudfront
via: 1.1 4bbc14b5834fc74ccd249b954b43a08c.cloudfront.net (CloudFront)
x-amz-cf-pop: OSL50-P1
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: ncSFQlZj71-fHM_finid9YYvtJsCHwCaK6fL8rhfE6Hg-HDypXe3pg==
age: 54574

And this result from Spain (where no access-control headers are NOT included):

HTTP/2 200
content-type: font/woff2
content-length: 11164
last-modified: Fri, 13 Jan 2023 20:03:47 GMT
x-amz-version-id: vZw9469Ogk6XEvU5RIQmB288hzwQr6zG
accept-ranges: bytes
server: AmazonS3
date: Thu, 09 Feb 2023 10:35:27 GMT
etag: "d08677b723b410a78debca060c4d2ca2"
vary: Accept-Encoding
x-cache: Hit from cloudfront
via: 1.1 c95bbb2353ba80a0b30261c24e526ab4.cloudfront.net (CloudFront)
x-amz-cf-pop: MAD56-P4
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: ux_suZMPIzk8iWSiESC9FyY6-soMs4u809-brTT00YHjRnEFpjZtug==
age: 1769

If we connect by VPN to Norway in Spain, we get the correct result again as the request from Norway.

There are some similar threads, but seems like these are not strictly the same and relates to some other issues. relates to the use of OPTIONS