Yes, it is defined relative to the meshes origin. The handle if you like is always at 0,0,0 and the axis are fixed. Positionmesh, Rotatemesh, Scalemesh just move the verts around this point. They do not change the box you have defined. Typically you would find min x,y,z of all the verts and then the box would be defined from min x,min y,min z to meshwidth(),meshheight(),meshdepth(). (As an aside it seems a shame that blitz does not expose the bounds for a mesh; it does of course know what they are - it calculates them when meshwidth() etc is called or at renderworld - which would save having to find them again).
You can of couse centre the verts on the mesh origin using fitmesh should you want to and then define a box based purely on meshwidth(),meshheight() and meshdepth() since the bounds would then be known. For instance -Meshwidth(mesh)/2 would be the start position and the end would be at +Meshwidth(mesh)/2 and so on. So using Fitmesh mesh,-meshwidth(mesh)/2,-meshheight(mesh)/2,-meshdepth(mesh)/2,meshwidth(mesh),meshheight(mesh),meshdepth(mesh) would centre the mesh on its origin and the required box could be defined in the same way.
Boxes are affected by entity orientation. They are not effected by entity scale AFAIK, which is a tad annoying, but perhaps necessary given how weird scaled space can become.
None of the mesh commands effect them at all. You need to adjust them accordingly and of course rotating the mesh around its local axis may result in a better or worse fitting box. There are I believe algorithms to find a good fitting box, but from what I have read they are completely non trivial, at least from my rather limited perspective.
You can of couse centre the verts on the mesh origin using fitmesh should you want to and then define a box based purely on meshwidth(),meshheight() and meshdepth() since the bounds would then be known. For instance -Meshwidth(mesh)/2 would be the start position and the end would be at +Meshwidth(mesh)/2 and so on. So using Fitmesh mesh,-meshwidth(mesh)/2,-meshheight(mesh)/2,-meshdepth(mesh)/2,meshwidth(mesh),meshheight(mesh),meshdepth(mesh) would centre the mesh on its origin and the required box could be defined in the same way.
Boxes are affected by entity orientation. They are not effected by entity scale AFAIK, which is a tad annoying, but perhaps necessary given how weird scaled space can become.
None of the mesh commands effect them at all. You need to adjust them accordingly and of course rotating the mesh around its local axis may result in a better or worse fitting box. There are I believe algorithms to find a good fitting box, but from what I have read they are completely non trivial, at least from my rather limited perspective.