Ciao belli!
(For transparency: @antocuni and I are part of the PyScript team at Anaconda - I’m mostly working with MicroPython in a WASM context at the moment, although this will likely change in the new year.)
Some random, high level thoughts that could probably do with refining:
on web-assembly as basically just another CPU target.
OS - oh my. I think of Emscripten/WASI as something akin to win32, libc, POSIX level abstractions: they are the layer that brokers between our code and “device” capabilities such as a filesystem, network interfaces, and other “hardware”. There’s more subtlety to this context, and things are moving fast in this space… hence Dr.Evil air-quotes around “hardware” since “hardware” can, for instance, mean the browser sandbox.
The abstract notion of “Python”. Folks usually think Pyodide (for good reasons - an extraordinary amount of great work has gone into it) – but it’s not the only “Python” in WASM town. There is, of course, CPython (based on Christian’s wonderful work) and MicroPython (which has a webassembly port, that has been gaining recent attention and work) and Zython (zython.org) - a version of Python built with a Zig based alternative to Emscripten. I can’t help but think that we, as a “scripting” / interpreted language, will also be walking / paving the same cow paths as folks in the Ruby, Lua and similar communities. I mention this diversity of interpreters in the hope we are able to share and build together, rather than re-invent various types of wheels. It isn’t so much a technical challenge as a cultural one requiring empathy, an appreciation of the diversity of the eco-system and an open mind/flexibility to allow us to both contribute and cherry pick from aspects of this area of concern. I hope we can think of ourselves more like musicians in a symphony orchestra (contributing to something greater than the sum of its parts) rather than soloists trying to play over each other. 
TK et al - if we removed tkinter from Python then turtle doesn’t work, and a million teachers and their students will raise their voices in protest (we had to pull a few funky hacks to get tkinter working properly in the version of Python we bundle in the Mu editor, for this very reason… one of our primary groups of users – teachers – told us they wanted turtle). I recently mentioned to @brettcannon that tkinter is to Python UIs as Roman numerals are to counting… i.e. it’s old, and there are perhaps “more modern” or feature-full ways to achieve the same ends, but folks still use it for all sorts of subtle technical, historical and cultural reasons, and we should respect that. YET… while web-assembly maybe just another CPU target it’s also often conflated with running in a browser context. Clearly this is not the only way to execute WASM given projects like Wasmtime. But it feels odd to port tkinter to the browser, or create bindings (in some way) so Wasmtime might run a Tk based app, in the same way that it would feel odd to add Roman numeral capabilities to Numpy - I mean, you could do it, but it feels like a strange thing to do. Brett made a fascinating point, during the recent TalkPython podcast, about the scope of Python… “Python” being the language separate to the Python standard library, while acknowledging that they are fundamentally intertwined. I like this, and it is important for several reasons:
- In a web context, thanks to network costs, you only want to download the things you need. Python in the browser probably doesn’t need most of the standard library. Or, put another way, how do our users get the version of Python + a standard library that they require to fulfil their diverse needs…? In this context “batteries included” isn’t really a feature but a burden. Having a clear story about this will help us better define what we mean by “Python in the browser”. Damien et al over in MicroPython have lots of experience in this area, because you clearly have to make choices about what to include (or at least, how to configure what to include) when you perhaps only have 256k of flash memory and 16k of RAM.
- I know there are moves afoot to retire aspects of the standard library. As I understand it, these are very conservative in nature and for every “surely we don’t need this any more?” there are a greater number of “but we still use it for X!” answers. I wonder if anyone has explored means of partitioning the existing standard library – or perhaps defining subsets of the standard library – such that stuff isn’t so much thrown away, but thrown into different buckets where each bucket has different support, activity and maintenance characteristics. But this starts to feel like we get to meet…
- The elephant in the room: packaging.
I won’t say much on packaging, except that I think in 2000 years time digital archaeologists will look at us and say something like, “hey, they had the same problems we still have”, in the same way we do when we look at Roman inventions like hypocaustum. I’m reminded of Kierkegaard’s comment that I’d paraphrase to, “packaging isn’t a problem to be solved, but a reality to be experienced”. 
There’s a danger, as engineers, that we see everything as a technical problem “to be solved”. I can’t help but think it’s another musical analogy: I like classical, you like jazz and she prefers hip-hop. Let many flowers bloom and perhaps sometimes we should just appreciate the dynamic, diverse and colourful world in which we live while being thankful for our own little corner of it.
TL;DR: (as usual) perhaps the most important challenges we face will be of a cultural rather than technical nature. If we keep this in mind, our “technical” outcomes will be richer, and reflect a more nuanced or enlarged view of the possibilities. Given the crowd on here, I’m definitely teaching granny to suck eggs, but I’m always fascinated by this intersection of technology and culture.