I'm actually seeing the opposite results: your sample extension works for me in Safari Technology Preview 202 but does not work in Safari 17.6.

Is it a normal/usual/expected practice that a Mac App Store submission of a Safari extension takes 3 weeks to review? No, never. Request an expedited review.

This is likely a Launch Services issue. See my blog post and the appendix: https://lapcatsoftware.com/articles/2024/12/2.html See also FB16144327 - Xcode clean of a Safari extension app causes the extension to disappear from Safari Settings https://github.com/lapcat/SafariExtensions/issues/54

Launch Services gets confused. See my blog post, especially the appendix about Safari extensions: https://lapcatsoftware.com/articles/2024/12/2.html It's really best to use a different bundle identifier during development. I append ".debug" to mine.

You said that this bug was "fixed in macOS 13 Ventura", but i'm currently on macOS Ventura now and experience this bug. No, that's not what I said. I said, "One notorious bug was the case of the disappearing Safari extensions, introduced in macOS 11 Big Sur and finally fixed in macOS 13 Ventura. In this blog post, I'll discuss a current bug [emphasis added] involving multiple versions of the same app installed on one Mac."

I would use Generate Info.plist File in your build settings. And you can build-configuration-specific values for Product Bundle Identifier. Unregistering the app is a temporary solution, but the problem will likely recur.

Is it a pinned tab? https://bugs.webkit.org/show_bug.cgi?id=286759

I filed a WebKit bug about this here: https://bugs.webkit.org/show_bug.cgi?id=290922 I've had several users of my extension request custom headers, though I'm not sure which headers exactly.

There is no connection between native UserDefaults and JavaScript browser storage. It appears that you're writing to one and expecting to read it in the other, but this is a misunderstanding. Each API is self-contained.