radial gradient control handles are wrongly placed

Reproduced with Inkscape 0.46, 0.47, 0.48.2, 0.48.3.1 and 0.48+devel r11582 on OS X 10.7.4.

 <defs>
  <radialGradient
   id="ReflectionHighlight"
   gradientTransform="translate(-0.5,-0.5) scale(2.0,2.0)">
   <stop
    stop-color="#FFF"
    offset="0"/>
   <stop
    stop-color="#000"
    offset="1"/>
  </radialGradient>
 </defs>

Known underlying limitation of Inkscape: the hand-coded gradient uses "objectBoundingBox" as 'gradientUnits' [1] (this defines the gradient transformation(s) to move and scale relative to the bounding box of the object which has the gradient applied), whereas Inkscape (currently) only fully supports 'userSpaceOnUse': While the initial rendering of such a gradient with 'gradientUnits="objectBoundingBox"' in most cases is correct (and corresponds to other SVG viewers), the scale and transformation defined in that hand-coded gradient definition appear to be incorrectly converted to 'userSpaceOnUse' whenever the object (or the gradient itself) is edited in Inkscape (e.g. moved).

Other reports mentioning inconsistencies between rendering and position of handles of gradients with "objectBoundingBox" gradientUnits:
Bug #168146 “Wrong bounding box calculated for objectBoundingBox units”: comments 5-10
Bug #970355 “Regression: Radial gradients with offset focal point using 'objectBoundingBox' incorrect (zoom-dependent)”: comments 4-5

---
[1] <http://www.w3.org/TR/SVG11/pservers.html#RadialGradientElementGradientUnitsAttribute>

Attaching extended test file with (hand-coded) variant using 'gradientUnits="userSpaceOnUse"'.

(Note: added variant has not been optimized (e.g.for minimal transforms), nor validated. Inkscape renders it the same as e.g. Squiggle (Batik 1.7), Firefox 14 and rsvg-view-3 (librsvg 2.36.1))

Still confirmed.

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15073 (GTK3)