I don't think the execution model you mention, which results in the absurdity of C style transitive includes polluting the global namespace, will ever be changed though.
There is a proposal at https://bugs.ruby-lang.org/issues/19024 to change this but, as you can see from the comments, it’s a bit tricky to get right while preserving backwards compatibility. (Whether that conversation makes you more or less optimistic about the chances of it ever being changed is up to you.)
Searching for a mismatched/missing _end_ is preferable to having a line or block get accidentally unindented and end up still "working" (running) while producing very confusing results.
Moving blocks of code in Python requires great care, especially since the editor cannot reasonably guess which scope level the paste should go into.
Also, the lack of an _end_ or bracket as with other languages means the editor cannot visually assist with identifying block boundaries. To be fair though, my vim-memory of using % to bounce between start/end brackets doesn't work in Ruby because of the begin/end words instead of matched symbols :(. However, RubyMine does show the beginning of the block as an unobtrusive popup at the top of the window when your cursor is on the _end_ keyword. That's super handy when there are several blocks closing in succession.
Even when I was new to python, the only problem I ever really had with this is when I mess up and copy the first line starting at the the first nonwhitespace character so the relative indentation is wrong. When do you ever move a block and not know what scope you want it in? At most, with really long blocks, you fold the more deeply nested blocks before pasting.
> Also, the lack of an _end_ or bracket as with other languages means the editor cannot visually assist with identifying block boundaries.
No, it doesn’t. In practice, editors usually don’t, but they recognize the beginning and ending of blocks, and use it for folding, which means they could insert phantom labels (as editors often use for blame information, inferred type signatures, etc.) to provide informatiom about the block ending (and even align them to indicate the indentation level corresponding to each ending block.)
An existing line of text is not necessary for editors to provide feedback.
Put "runtime macros/matchit.vim" into your .vimrc. Or for even better support add the matchup plugin. https://github.com/andymass/vim-matchup
matchit/matchup extends this to language specific delimiter words. This animation https://github.com/andymass/vim-matchup#screenshot shows how you can iterate over multiple sequences like if/elsif/else/endif.
The issue with Ruby specifically (which doesn't exist in other common languages that have bracket- or keyword-delimited blocks) is that non-keywords can start blocks. So it's difficult for an editor to determine the likely matches, and it's even harder for a human. That's my vague recollection of the problem that I ran into numerous times, though it was about a decade ago.
This suprises me. I've missed `end`s before as much as anyone, but I guess as an OCD reformatter (prettier, IntelliJ, rubocop, etc.), they show up VERY OBVIOUSLY and right quick. They've never even been an itch, much less "pain".
... and decent first party docs, actual code modules rather than “execute every source file in the global namespace”, a first party Windows build, etc., etc., etc.
If the Ruby community can't acknowledge the real things holding it back compared to other available options, well, that makes it that much harder to catch up.