When resizing views in a SplitView by moving the handles, the size of every view to the right (or below if vertical) gets affected. So if you're moving the last handle you get the behaviour I would assume most people would want (only the views adjacent to the handle get resized, and you're essentially just changing the ratio between them), but if you're moving any other handle everything else to the right moves. The only straightforward workaround is to have 3 views with the center one being the "fill" one, but that doesn't work for more than 3 views.

I can tell this behaviour is probably intended in some way, or at least taken into consideration in the documentation so not a bug, but it's clearly not what most people would expect/want. Using SplitViews of more than 2 elements (3 if using the workaround) is very inconsistent.

The SplitView QML type in general is a bit of a black sheep in that it's more like a layout but is under QtQuick.Controls. It uses the typical attached properties you'd find in a layout like preferredWidth, fillWidth, etc... but they don't work at all like they would in an actual layout type. For instance, another common requirement of a SplitView would be to have N views that initially are uniformly spaced, which in a layout would be achieved by setting fillWidth/Height to true in every child. This not only doesn't work in a SplitView (because only one child can have fillWidth/Height set to true), but you can't even easily set the views to start uniformly spaced. You have to initialize the preferredWidth/Height to the parent.width/parent.count in the Component.onCompleted signal handler (because if you do it as an actual binding the layout resets on resize, so you must do it in onCompleted), and even then the result isn't perfectly uniform because it doesn't take into account the width of all handles. Obviously this is very easy to fix but I'm just trying to illustrate how complicated setting up a SplitView with even the simplest of requirements can get pretty complicated.

I feel like SplitView is in need of an update to at least support these common use cases, if not a complete rework to get it to be more in line with how other QML types are used.