> It’s rare to need to background a console editor,

LOL. My experience with an average of 5-6 backgrounded vims *per each named tmux session" which I use to keep track of different source files I'm working on goes against this. Sure, I can use vim's windows, but I don't want split screen usually (I'll use the other terminal I have open if I do). I don't use tmux's windows either really. It's more a way to preserve session when changing workstations (these are remote terminals), and preserve against network drops. I use each tmux session as a contained work environment for the most part. I do all my software development using vim on a remote server, and have for most of the last two decades. I've worked with numerous other developers that work similarly for professional projects, personal projects, or both.

Let's just say that there might be people that use the combined features of terminal applications, terminals, and remote connections in ways that you might think were rare, but actually have large following and leave it at that. :)

You may choose to do that but it isn’t required, I listed three alternatives that work fine and there are probably more. Going in and out of an app all the time is inefficient.

If I don't want a separate SSH connection for every tab, then some in-terminal level management is required. Additionally, it's not really that inefficient. It's no different than alt-tab in windows to background and foreground apps. In this case, it's like alt-tab when in a remote desktop connection.

But in the end it's not about whether it's efficient, it's about whether it's rare, and I think it's not from the different vim users I've encountered, which may be an entirely different subset than the ones you have.

It sounds like you’re already happy with vim, so why not keep it? Also the micro keybindings are configurable, so not much to see here.

I wasn't complaining about Micro. I wasn't complaining about vim. I was just noting why terminal applications don't generally use those same key bindings historically, and why it still matters today. The only reason we are off in the weeds like this is because of your assertion that it's rare to need to background a terminal editor, which doesn't match my experience at all.

I just open a new tmux window per-file I edit, named after the file. Well, I do still bg vim processes sometimes, but mostly I do the per-window vim thing. I even have a vim wrapper to do this so that editing files from cscope automatically starts a new tmux window with the vim in it and returns control to cscope.

It requires a modified setup, but you can set vim up to open multiple unsaved files in a single process. Not splits ir windows, but buffers. I have bindings set up to quickly do :bn and :bp and :bd. Your tmux usage sounds like mine, and if you did not know that there was depth to vim buffers this may be valuable to you.

I'm aware of stuff like that, and things like nerdtree. In the past, I've had many boxes I might end up on so I kept coming relatively stock to the distribution. In the last four to five years it's been primarily one box, so I've finally started putting in more advanced features slowly.

There are benefits to being comfortable in a somewhat stock Vin, and there are benefits to having it highly customized. I find the benefits imparted might be outweighed by the discomfort when it's not as you expect if your work flow forces that situation on you, so as my work flow has changed with the type of work I do, I've tried adopting different vim strategies.