No fix yet, but it seems worthwhile to document some of my diagnostic results so far which more closely isolate the underlying puzzle to me. I.e. why does the logical connection point change (with define_shape) when the soma 3d points do not change. Note that the logical connection point should always track the location of the parent connection (3-d location of center of parent segment). The distance between logical connection point and first 3-d point of a section should be invariant. Thus, when one moves the root section (usually soma) that moves the rest of the tree a corresponding amount (and updates the logical connection point to keep the invariant).

Anyway, what I observe is that the soma 3d points are exactly the same before and after define_shape. Also, of course, that means the average and center of the soma points are the same. However the logical connection point starts out wrong and after define_shape gets updated to be the same as the soma center point.

The observations are:
before diam_shape

average  [-0.5143091442684332, 0.224248896752085, 0.0, 7.583558775129772]
center  [-0.5143091678619385, 0.22424888610839844, 0.0, 2.4370133876800537]
logcon  (1.0, [-0.3851528465747833, -1.1602301597595215, 0.0])

after diam_shape

average  [-0.5143091442684332, 0.224248896752085, 0.0, 7.583558775129772]
center  [-0.5143091678619385, 0.22424888610839844, 0.0, 2.4370133876800537]
logcon  (1.0, [-0.5143091678619385, 0.22424888610839844, 0.0])

Note that the code for those calculations is

def logcon(s):
    lcf = tuple([h.ref(0.) for _ in range(3)])
    lc = h.pt3dstyle(1, *lcf, sec=s)
    return lc, [ref[0] for ref in lcf]

printed by print("logcon ", logcon(cell.axon[0])) and

def vec3d(s):
    vecs =[[] for _ in range(4)] # x, y ,z, d
    for i, f in enumerate([h.x3d, h.y3d, h.z3d, h.diam3d]):
        for j in range(s.n3d()):
            vecs[i].append(f(j))
    return vecs

def paverage():
    soma3d = vec3d(cell.soma[0])
    print("average ", [sum(vec)/len(vec) for vec in soma3d])
    print("center ", [(vec[0] + vec[-1])/2.0 for vec in soma3d])

The problem is that the center of the original soma neurolucida contour is not the same as the center of the processed contour that ends up becoming the linear chain of 3d soma points. The former is

-0.385153	-1.16023	0

and looks like (Note the tip of the green line)

and the latter is (see the green dot on the screenshot)

-0.5143091678619385, 0.22424888610839844, 0.0

I'm wondering if the least disruptive fix is to construct the processed soma (defined by the h.soma[0] 3-d points) so that the processed soma has the same center as the original neurolucida contour.

What would be the issue with updating the style (logical connection points) after the soma section (points) is created from the counter with the real section center?

Setting the processed soma center to the same center as the original neurolucida contour would not work. You would need to translate the full cell then, which would be especially bad because the coordinates from the file wouldnt match the loaded point coordinates anymore, which isnt a problem inn itself but would throw people off for sure.

If you are talking about changing the way the contour is turned into the section, to more closely match the contour shape, that would work I guess if one finds a way to preserve the center in that process, although it would change the soma shape, which is a change that would effect anyone using neurolucida files. While correcting the logical connection points is only noticed when using define shape in combination with neurolucida files.

Let me know if you agree with the fix embodied in #2981

Looks good to me as far as I understand it.