My bad - I should have made it clear that I assumed "changing val" implied deprecating/removing val in favour of let.
One generic way I was thinking it could be implemented, from a very naive perspective is that:
let (x = 5, name = “Mark”) {
///
}
under the covers generates the equivalent of something like:
class $1(val x: Int, val name: String) : Closure {
fun run() {
// this has access to immutable, class local vals x and name
}
}
$1(5, “Mark”).run()
I’ve not looked at how the closures are actualy generated so not sure off hand if this is anything like whats really done currently. Altho, given this isn’t really a closure to pass around, it could just generate a method:
fun $1(x: Int, name: String) : <TypeOfLastStatementReturn> {
//
false
}
This would allow for dong “return let(…) {…}”, the conumdrum I just ran myself into is dong:
val foo = let (x = 5, name=“Mark”) {
// locally scoped x and name, return something
}
In trying to replace val, I’ve just come in full circle 
which maybe implies such lexically scoped vals are separate things entirely.