The new variables system desperately needs an improvement!

[Lumios64]

Preamble

Excuse me in advance if I'm forgetting anything, I haven't touched gdevelop in several months since I got busy with real life and even had to get a new PC.

This mostly concerns this post on the forum and all the problems I have that stem directly from this new system. I would suggest a quick read, at the very least, 4ian's starting post to get the full context on the issue.
https://forum.gdevelop.io/t/new-unified-variables-and-variables-declaration-in-gdevelop-5-4/58723
Note that I wasn't aware of it until I got back to GDevelop, this is news to me.

And just to clarify, I do not have any issues with this new system in theory, but its implementation in GDevelop really leaves lots to be desired. In fact, a few of the opinions left on the forum are raising similar points to this discussion.

Using variables in expressions

I don't know when that got chopped, but I'd assume around 5.4, too. It is currently made more difficult to add variables because the functions to handle them got removed from the expression builder. Another user opened an issue about it, which has been left stagnant for quite a few months.
#6941

The problem with this way of handling things is that I'd have to memorize every single variable, or write them down on paper. This can't be good for anyone, not even beginners. In IDEs or GEs like godot that use code, that is not a problem. I can just hit "home" to check what variables I wanna change and then hit "end" to get back to where I was. Because GDevelop is a "no code" game engine, this makes it an issue for programmers because they'd have to back out of the events tab and open the variables menu. The old system allowed me to simply ask that I wanted to use a variable and it would give me a complete selection of all declared variables that I could choose from.
What's worse for me, and my workflow, is that I usually tend to give the same name to variables for both global variables and scene variables which this can't differentiate. Based on testing on my end, it seems to give preferential treatment to scene variables over global variables if there exists both a scene and global variable with the same name.

My proposed solution

This goes without saying, but in some form variable() and stringvariable() should come back, either there should be a function call like before, or as I mentioned on the linked issue, a pseudo expression should be used in its stead like the object variables. Maybe we could have global.MyVar and scene.MyVar. Or third idea, there should be a dropdown menu that lets the user select whether they want to use the scene variable or the global variable if both of them already exist. Anything to help the system distinguish what variable I want to use would potentially avoid problems and frustations later down the line and offer a quick and easy band-aid to the few people like me who give the same names to global and scene variables. Another thing with that that would be great and nifty to see is if it gave a list of every variable upon interaction with the input text. It keeps the current system the same and solves both problems simultaneously.

Temporary/Disposable variables

Before 5.4, I would typically declare variables I reuse in code, for example "Health", "Score" and "Gold", but not variables that are only used once I.E, they are discarded immediately after use.

In most programming languages some variable names, while not reserved, see a specific usage by most developers. "i" for example is often used as a dummy variable for loops and iterators, and what's great is that's all you need. However, unlike most programming languages GDevelop doesn't support redeclaring a variable. If a variable was once declared as a number or a string, that cannot be changed. Due to this caveat, the new system requires everybody to declare three concurrent disposable variables if they wanna use dummy variables in their projects, one would be called "tempstring", one would be called "tempbool" and one would be called "tempnumb". Whereas, in the old system, I could simply use "i" and change what it is on the fly, if I wanted to store some text, I could, if I later wanted to store a number instead I could no questions asked.
It's made extra cumbersome by the extra steps it takes to declare the variable in the first place. I'm a keyboard guy, it's easier and faster for me to type int i = 0; in hundreds of scripts than it is to open a menu for each scene just to add three disposable variables that will be used once in a context and then overwritten in the next. And before you ask "Why not just use global variables?", scene variables are more, let's say, "compatible" with pretty much everything in both the editor itself (example: saving to a file if you want a save progress button in your game is only available to scene variables last time I checked) and external add-ons. That's also why, as I mentioned earlier, I declare identically named scene and global variables because the global variable is supposed to carry the data between scenes while the scene variables just do all the heavy lifting. This is a problem for another time, though.
Anyway, back on topic.
That's usually my biggest gripe with "no code" game engines like Clickteam Fusion, too much of my time is spent in menus and I know nothing of javascript and typescript, so I kind of have to use the "no-code" interface which was fine until this update dropped. And I mean it, this was not a problem before 5.4 since everything could be done directly from the scene events tab. Ideally, you would want the developer to spend less time in menus and more time actually working on the game.

My proposed solution

Adding an action for declaring new variables in the events tab would both keep the spirit of the new system and it would actually teach people how to declare them properly in programming languages per one of the stated goals of the New unified variables and variables declaration in GDevelop 5.4. In its current form, you don't really learn anything more out of it than the previous system. The only difference is it encourages users to interact with the variables tab which as I said is inconvenient to use when I have to hold down/mash the tab key, and even with the mouse the whole menu feels tacky and unpleasant to use, at least it is for me.
This is especially problematic if I refactor my project. It would leave many declared, but unused variables unless I delete them manually and that can't be considered "good practice". My proposed solution simply relegates this menu to a simple overview since now all the variables would be declared in-code.
Heck, this could probably teach control flow to new people because any new user would have to use the "At the beginning of the scene" condition to initialize the variables before actually using them.

In summary/Long story short/TL;DR

With the new system, I spend an inexorably longer amount of time in menus than ever before due to this tiny small microscopic change, and that's not something I want to deal with.
I really do hope something, really just anything will be done about it because a good number of people would be bothered by this, not because it is a change, that's silly, but because they use GD with shortcuts, very little mouse interactions, etc and the GUI is for the most part hit-or-miss with some parts being responsive and well-designed, and others acting weird or just designed poorly like the variables menu. Variables being a core part of GD is what's making this issue particularly maddening because that's not just something I can avoid, or well I could just continue using godot or stride to avoid it. Sad thing to say too since GDevelop now has 3D support which was a major contributing factor in getting me interested in the engine again. ¯\_(ツ)_/¯