Vadim Belman

@lizmat whenever a discussion about language-specific behaviors comes to the point of changing a method semantics, it is always considered a bad idea to rely on caller's language version. First...

> About "who is the caller" or rather "where is the boundary", my current thinking is that a sensible boundary might be the compilation unit - because that is the...

> That 6.c code calls .child and that method behaves...exactly like the 6.c code expected and how it was documented for 6.c at the time that 6.c code was written....

Ah, and one more thing. We are biased in our attempts to find a solution for core versioning issues. It worth stepping back look from user's perspective.

It feels wrong to have a problem-solving issue discussed in [a commit comments](https://github.com/rakudo/rakudo/commit/f31a6d56dcb39aec1286f79018379e8f8a705b27). So, I'd try to move it from over there. >> On Monday, 17 April 2023 15:36:24 CEST...

It just've crossed my mind that with a proper coercer `multi method COERCE(CORE::v6c::IO::Path) {...}` we can rely on `my IO::Path() $path = ...` to give us _our_ language version of...

> Why would I need to know the language version of that module? It will work like advertised because it's getting objects that behave like documented at the time the...

> Sorry, but that's a trivial excuse. If we went with that, we could never do any risky change ever, because there's always the chance of some unforeseen problems it...

> but what gets _distributed_ (and thus has a higher expectation of being written to work on other systems) is enforced by a given authority's policy. I'm not even sure...

~~Aren't new subdirectories are created for new Rakudo version in custom locations?~~ Ignore, messed up with precomps.