Good point, I also want things to work offline. By "remote" here I was also thinking of scenarios like:
- Connecting from Windows/macOS host to a local VM
- Connecting to a build server over LAN (I have a beefy PC but prefer to work from my couch)
Both work offline just fine, but from tooling perspective you are connecting to remote host over the network
Not very small; most corporate non-Windows development uses containers, I'd bet on the ratio above 90%.
Not that developers want remote-first experience, but they face it. Containers in this regard behave like remote systems, even when run locally. A tool that helps juggle multiple remote contexts in a sane way may be very helpful. Say, tmux does a lot to help, but more is of course possible.
You might want to expand on who "we" are here, because to me it seems to be a very small section of developers who want a "remote-first" experience and most (if not everyone) I speak with want software and tools that work local/offline-first, including our dear development environment.
If a tool requires a internet connection to work (so this "remote-first container-based world" you mention), I don't think either me nor many of the developers I know would even give it a try, because we need to be able to use our tools regardless if we have a working internet connection and/or the service-provider has downtime.
In fact, the only ones I know who are using a "remote-first" environment are developers who are forced to do so by their employer, and it's not a short-list of complaints about it when we meet over beers.