When editing by hotspots (only) in 3D, GLOB_SCALE skips to 100 instead of its real value.
Note that it's advisable to have lower LOD when stretching, but it can be driven by GLOB_FEEDBACK_MODE.
Real problem is that there are quite many objects with, like, different thicknesses or any kinds of sizes/geometries in different LODs, and if hotspots are placed behind selections driven by LODs (since they should be placed onto, like, a surface that is being affected by changing LODs), actual hotspot positions could change by stretching, and, since this doesn't work, this leads to such hotspots making cannot be stetchable. And this bug cannot be avoided, since one doesn't know what the last LOD was before stretching.
This behavior is also inconsistent with 2D, since in 2D returned GLOB_SCALE always shows actual (right) LOD.
In attached-zipped test object, in 3D a sphere is drawn according to actual GLOB_SCALE and if scale is set to, like, 1:10 in 3D (warning: separately form 2D), sphere changes its radius while stretching.
If isBuggyIn3D is set to True and 3D scale is 1:10, hotspot cannot be stretched.
Thanks for this detailed post and sample object! We looked into it, and it is indeed a bug, the editing preview/feedback should follow the actual scale! I recorded the error (#254207), and we will fix it when we can.
At the same time, in your object you used the parameter script (master script run as parameter script actually) to record the glob_scale, and it indeed returned 100. That is a different case, as the glob_scale simply doesn't work in the parameter script at all, so it always returns the default/dummy value of 100.