My behavior wouldn't work here because the isometric view is for 2:1 instead of 60 degree isometric. It could be an idea to somehow work with it, but I haven't given that much thought.
My idea may not even be simpler. I've been working on a example off and on to get a working example of my idea. but I haven't put a lot of time into it yet.
The z-ordering is too hard if all the cubes are placed. So only sorting them per hexagon is much simpler. To actually sort them i'd use the filimation approach which compares all the blocks and builds a tree graph of what is in front of what. Which is what my behavior does and works great for sorting isometric in most cases.
The collision detection is simple enough. If the player and a cube are visually overlapping you can then compare their isometric positions to do a bounding box collision check in iso. You could populate a 3d array as a 3d grid of cubes as a lookup but it shouldn't be necessary.
Everything is per hexagon and is the player overlaps multiple hexagons, then each would need to be updated.
What i'm currently working on is a way to update the cube positions on a hexagon. For that I need to know which of the six sides the the blocks exit and the the order of each of the three axis (x,y,z). Like if only the y and z line were used like in your top right image: x in front of z, y and z the same, z in front of y. I can move any line forward by adding the same value to each isometric position, which won't change the visual location.
The player's position can be different per hexagon because of this order, so to remedy the transmission from one hexagon to another, it needs to keep track of what line the current block it's touching is on (x y or z).
It may end up not being easier than what you're doing but it works in my mind. Once I get it working I probably can identify some unneeded cruft and simplify it. It's just taking longer than expected because I haven't had much time to work on it.