Yes, in my experience, scope is a huge issue for beginners. This is why environments like blockly and scratch out so much effort into reifying scope with colorful blocks that “snap” together, so that scope becomes something more tangible.

That sounds better than making everything global.

Depends. Also in my experience I see a huge dropoff in coding interest when students move from the fun environments I mentioned, to the professional tools programmers use. Unfortunately there's not much of a middle ground, and there's only a small slice of students who "get" the stuff (like lexical scoping) we throw at them at such an early age. I think we are doing them a disservice by trying to make professional coders out of young learners.

Many of us who learned on systems like basic became professional programmers eventually, so I don't really see why it's so important for early tools to mimic what software developers use. Excel is an example of a language with globally-scoped variables, and it's used by more people than all other languages combined to successfully run everything from personal finances to business operations. SQL is another example of a language that is used by non-programmers that doesn't have the typical lexical scoping rules. So it's certainly possible to build complex systems without lexical scoping, and it seems like non programmers “get” this version of programming moreso than even Python, which is lauded by programmers for how supposedly learnable it is.

That's for syntax, not scope.

Scratch doesn't have lexical scope.

I think it is. It solves a problem, that is of course very real and urgent in programming, but does so by adding a layer of abstraction. And I think abstractions have to be introduced sparingly and gradually. Likewise functions with arguments. I still find this to be a hurdle when helping people learn Python, and they don't naturally use functions and scoping unless I goad them into it. Many of them won't do anything beyond writing basic linear scripts, which is OK.

My first language was the original line-numbered BASIC. I think a benefit was that you could pretend to think like the computer, and run the program in your head or on paper. Naturally we were led to experience the mishaps that scoping overcomes.

Nowadays, a motivation is showing how they can import a package, and use its functions, without having to understand the internals of the package. The most primitive reasons are named function arguments and scoping.

I would argue that introducing such concepts in easy to understand ways is the task of the IDE for such learning languages. E.g. Thonny does a great job of explaining how locals work during debugging by using a multi-window mode where each stack frame gets a separate window that shows just that function's code (with current statement highlighted) and its locals. It also takes care of recursion - you can easily see how every recursive call adds a new window, and each window has its own set of variables.

Ah, I had forgotten about Thonny. For a while it seemed like they weren't keeping up with Python versions.

Hmmm... even after just a few minutes, I'm impressed. I prefer to use beginner tools for my own work, even though I'm actually quite experienced, because it gives me a chance to familiarize myself with the things that I would actually recommend to beginners.

Also, it reminds me of another thing, which is that not just the language but also the tooling, can be a source of abstraction and frustration.

I've fixed this issues in Small Visual Basic: https://github.com/VBAndCs/sVB-Small-Visual-Basic sVB has local and global scopes, functions that return values, and subs and functions with parameters. Also, sVB is a semi object oriented language, that allow access instant properties and methods of objects. It has a form designer and a mini winforms lib, so it can easily create multi-form apps.