When perl 5 come out, they were forced to invent everything from scratch, but now, there are lots of mature, efficient and feature rich runtimes you can reuse: .Net, JVM, MoarVM, etc.

The problem is when the semantics of the VM don't match the semantics of the language, especially with regard to memory management, dispatch, process models, etc.

Yes, absolutely. It would be impossible to implement perl 5 on top of any of those VMs and get the same semantics.

But we are fantasizing about the scenario where breaking backward compatibility is acceptable to the point of removing support for XS.

So, does it make sense nowadays to keep using reference counting instead of a proper garbage collector? Deterministic destructor calls is a nice thing, but well, it seems most language designers are glad to sacrifice them in favor of proper automatic memory management.

Does it make sense to use the UNIX process model? isn't it better to move to a higher OS-agnostic abstraction? Actually, proper Windows support was one of the first things proposed on p5p related to improvements people would like to see in future Perls.

Custom dispatch semantics seems to be something you can emulate in most platforms at the cost of degraded performance.

So, it is not just that those platforms may have different semantics, it is that those platforms probably have the right semantics.

So, it is not just that those platforms may have different semantics, it is that those platforms probably have the right semantics.

I'm less convinced, having lived through a couple of big revisions of Parrot and what eventually became Raku. One reason Raku remains so stubbornly slow is because it insists on having a grammar so extensible that you can't even assume a single definition of whitespace.

When you bake the assumption that every call to the tokenizer has to be a virtual method into either the language specification or the implementation, you're going to expose the results of that assumption to everything.

but now, there are lots of mature, efficient and feature rich runtimes you can reuse: .Net, JVM, MoarVM, etc.

Isn't the problem always reference counting vs. tracing gc, though? If you expect DESTROY to run when your objects go out of scope, for example, most gc runtimes won't destruct objects in a timely fashion and I think some won't call destructors at all. I want to say dotNET core got rid of finalizers, for example.

But regardless of details, I agree that runtime-independence is the kind of aspirational thing that would make the pain of retiring XS worth it.

Isn't the problem always reference counting vs. tracing gc, though?

Yes, you have to choose between deterministic destruction or garbage collection.

Languages with garbage collection usually provide a with construction (that I think comes from LISP).

Nowadays it seems that everybody (or at least, most language designers) admits that having a proper garbage collector is something so good that it well worths the trouble of requiring those with guards.