Right, I feel like there’s a couple ways to look at this. I like the re-use of borrow for the mutable/immutable cases because it conceptually links the ownership relation as the ‘thing’ that the two different versions share. This parallel didn’t exist for the borrow/consume parameter modifiers because the ownership relation for those two keywords were different.
I take the point that we already have a keyword for mutable borrow, but I don’t consider myself overly pleased with the inout terminology. It makes some amount of sense as a parameter modifier where there’s already a strong metaphor of passing values in and getting values out of a function, but I think it strains the metaphor somewhat when extended to local ‘inout’ variables. I’m not sure this outweighs the added complexity of an entirely new specifier when inout is ‘right there,’ but I think it’s worth considering.
One way to avoid the compound keywords issue everywhere while also maintaining some of the ‘rule’ about borrows being immutable would be to invert the parameterization so that you would say borrow(var) x: Int = &…, and the rule would then be borrow is mutable immutable unless explicitly specified otherwise. This would maybe also suggest allowing borrow(var) as a synonym for inout in parameter position. But this is likely also coming from a Rust-inclined thought process. 