This is one of the biggest pieces feedback we've received both the tabs / splits in particular [1], and the more general issue of broader Vim compatibility [2].
We actually use a forked Vim implementation under the hood (libvim [3]) - as the modal-editing engine. So Onivim, in theory, _could_ support everything. The main issue is 'wiring up' features from libvim to our front-end.
We'll be focusing on this in our next milestone (July-Sep) - with the high level goals of supporting more traditional Vim workflows, Vim tab support, along with VimL plugin support and init.vim/vimrc compatibility.
Ultimately it's a prioritization problem - so having feedback like yours is really helpful, so that we can focus on the right priorities for that work.
- [1] https://github.com/onivim/oni2/issues/592
This is based on me personally. I use the vim plugin in VS Code. I wish it was closer to real Vim keybindings, search etc but I want to keep the overall handling of tabs and files.
So Onivim is very interesting to me, I have purchased it, because it looks like it will give me the combination of speed, plugins and conventional editing experience that I'm looking for.
We are adding Vim-style tabs as well (i.e. tabs are a view on to buffers, where a buffer can be any split etc as expected).
That said, you are right that a lot of people in Oni1 were interested in a "modern" (in heavy quotes there) way of doing tabs, where a split could have its own tabs etc, as is the way in VSCode etc.
I'm not really sure what the target customer/market is...Perhaps beginner Vim users that want a better modal editing experience than the Neovim plugin for VS Code provides, without having to sacrifice VS Code plugins? In any case, props to the Onivim team for the progress/momentum behind the project.