Q:

How does a BSP tree work for Z sorting?

I'm developing a 3D engine in software, and so I must compute Z sorting manually. I'm currently using the painter's algorithm to sort triangles and then drawing them back-to-front. This causes artifacts that I'm trying to correct. 

Would using a dynamic BSP-tree ensure "correct Z sorting" of triangles? Why? Because the bounding volumes of triangles would be similar?
Since I would have a single "world" BSP tree, would I have to remove and re-add any moved/scaled/rotated object into the tree?
Is it possible to add triangles into a BSP tree without the expensive cutting process? Why do you need to cut triangles on the axis planes anyway?
Is it faster to traverse a BSP tree from any angle, than to sort all tris each draw like the painters algorithm? 

A:

Using a dynamic BSP tree can ensure correct z-sorting of triangles, if you draw those triangles by walking through the BSP tree, and if you have only one triangle per BSP branch.  The basic idea is that each branch of your BSP tree breaks up space into two pieces (typically "in front of" and "behind" that triangle).  By checking which of those two pieces of space contains your camera, and drawing the other one first (recursing into the BSP tree branch for that space, if you're not in a leaf node), then you're ensured that you always draw the tree from back to front, which is exactly what you need for the painter's algorithm.
Yes.  Adding or moving triangles will require re-building the BSP tree, which can be very computationally expensive.  Most games with moving objects do not include those moving objects as part of the BSP tree for exactly that reason, and instead build a separate BSP tree for each movable object, and then pick an order in which to draw those movable objects using a more traditional z-sorting.
You CAN add triangles into a BSP tree without clipping them according to your BSP planes (so triangles may have corners 'poking through' the division planes), but doing so can result in errors in the back-to-front traversal of the tree.  In fact, there are many situations where it's impossible to correctly draw a set of triangles from back to front, simply because they overlap in a complicated manner (for example, it's possible to arrange three long, slender triangles in a loop such that each overlaps the next, and none is entirely "in front".  In this situation, the only way to make these triangles render correctly is to split the triangles, and z-sort the triangles after the split.  The BSP triangle cutting process typically handles cutting triangles which might have this problem automatically, while building the BSP tree).  But you don't necessarily have to cut triangles on cardinal axis planes, as you imply -- in fact, when building your BSP tree, it's often most convenient to pick one of the existing triangles in a space, and to use the plane of that triangle as the split plane for cutting the other triangles into "front" and "back" groups.
It is much, much faster to traverse a BSP tree than to sort triangles naively.  Traversing a BSP tree requires a vector subtraction and a dot product at each branch, while a sort requires.. well.. a sort.  So one is O(n), while the other is probably O(n*logn), depending on the sort algorithm you choose.  That can be a huge difference, when you're dealing with a large set of triangles.

