Mostly, people caveat some of their opinions with "I think" or "It seems". I do so liberally in this thread. But it becomes very tedious to read if you do it constantly in every sentence (even with abbreviations like "IMO"), so sometimes a statement is left bare. When this happens, it is best not to latch on to it and complain that this particular thing has been stated "as fact". It is clearly someone's opinion when viewed in context.
For example:
No caveat here – you seem to be stating it will cause a lot of bugs as a fact. But of course you aren't – everyone understands that this is just your opinion. But the words used here are extreme. It will introduce a lot of bugs? The var in if var x is "nearly invisible"? This is clearly hyperbole (IMO of course) and I think the discussion would be better without extreme characterizations like this.
What (I think!) you mean is that you can envision a hypothetical scenario in which someone might think it's an inout binding and that this could lead to a bug occasionally. And I in turn think that this is not going to be a problem in practice. Nowhere else in the language does var do this, including the very similar if var x = x that already exists. And current use of that feature does not suggest this problem is causing "a lot of bugs" as far as I know.
This is a phenomenon we get a lot on these forums, which I call "performative misunderstanding", where a possible but frankly implausible misinterpretation is cited as a reason not to adopt a feature. I think it's a real problem, because it worsens good proposals, for example giving us waffly names for standard library functions. It can cause us to skew the design towards the very first use of a feature, not the subsequent 1,000+ uses, all the while not actually making that first use particularly better.
I wouldn't. I'm not suggesting we accept a proposal without considering how the future direction of borrows and moves might interact with it – though I do think you're overestimating the closeness of the design of type-system-level moves and also the likelihood it will affect this particular sugar.
What said in the text you quote is that to keep this discussion on track and hopefully converge on a proposal we could run is that we first discuss the language as it is today, and then once settled on a good potential addition, we think about its interaction with future syntax for borrows.
I also think there is a flip side to the "we've done without this for 7 years"... which is that we should be a bit sheepish about that. It's not great that this clear pain point has gone unaddressed so long, and putting it off another two years because it might not quite fit with a feature that hasn't really been designed or pitched yet is not OK. What we will probably need to do is make a judgement call about the likelihood of future directions clashing, maybe with some early sketches of what that feature might look like. But that is going to be a long and probably pretty hand-wavy discussion, and I think it's best had after we handle the already hard-enough task of settling on a proposal that works for the Swift of today.