I don't recall the old discussion but looking at it now, I am wondering if the change is actually needed. What is this change making argument names consistent with? The base AbstractPointPen originally had baseGlyphName instead of glyphName and it seems the various sub-classes that you are changing were all duly using the same parameter name. What exactly is wrong with baseGlyphName? Is it because the segment pens' addComponent methods have glyphName? So what? One could argue that, given the two sets of pens have a different somewhat parallel history (and completely different API anyway), it's fine they have slightly different parameter names as long as they are consistent within each set.

PointToSegmentPen, GuessSmoothPointPen, ReverseContourPointPen, all inheriting from AbstractPointPen, already used glyphName instead of baseGlyphName in addComponent. I often stumble over this because my type checker complains that the method signatures are different. Sometimes a whole class is marked, see the attached screenshot. Changing the argument name in the base class is the least invasive fix IMHO.

There are also some mixins (e.g. _DecomposingFilterPenMixin) which are used in both segment and point pens, so there will be warnings about different argument names in them as well.

The newer addVarComponent uses glyphName and transformation consistently.

But of course you're right, there is no functional reason to change anything.

We hit a real-world issue this week that this PR would solve: RoundingPointPen calls its target pen with an explicitly named baseGlyphName, but ufoLib2 only accepts baseName, so we get a crash.

A workaround is possible, e.g., passing the argument positionally, but it would be nice to achieve proper typing and eliminate this whole class of error forever.

technically that's a bug in ufoLib2 because the GlyphPointPen subclasses AbstractPointPen (just like RoundingPointPen) so it should really have baseGlyphName like its base class..
in any case, the presence of mixins that are used by both APIs is a stronger argument for giving the two sets consistent parameter names. I just hope that we won't make other client code crash suddenly because they happened to use keyword argument with the old name..

@Hoolean are you sure this PR would actually solve that bug you pointed at? ufoLib2 GlyphPointPen still calls its parameter baseName whereas in @jenskutilek's PR the RoundingPointPen is calling it glyphName (instead of the previous baseGlyphName, in both cases you'd get a TypeError, unless you change ufoLib2 as well..