I don’t think glyphs in renamed_glyphs should be removed unless they also are in removed_glyphs.

"Rename Glyphs" should swap glyphs names. For example renamed_glyphs = {'A': 'A.alt'} means A and A.alt swap names.
"Remove Glyphs" should remove [not export] glyphs after that.

See https://glyphsapp.com/content/1-get-started/2-manuals/1-handbook-glyphs-2-0/Glyphs-Handbook-2.3.pdf#page=194

Remove Glyphs list
Will prevent the glyphs mentioned in the list
from being exported into the font. Automatically generated
OpenType features respect changes in the glyph structure,
e.g., if you remove all smallcap glyphs, then it will not autogenerate
the smcp or c2sc features. Useful for subsetting

and

Rename Glyphs list
Will exchange the glyphs mentioned in the
value with each other. Takes a list of rename strings of the
form ‘oldname=newname’, e.g. ‘e.bold=e, g.alt=g’. The glyph
previously stored as newname will now be called oldname
and vice versa. The parameter will update composites that
employ the glyphs involved, update automatic features where
necessary, and also exchange the Exports attributes of glyphs.
If you want to avoid the export of one the glyphs, make sure
that either their Exports attributes are set accodingly, or use
the Export Glyphs parameter

We have to update the names of the components in composite glyphs.
Building Monserrat with this PR now fails with the following error:

Traceback (most recent call last):
  File "/usr/local/var/pyenv/versions/fontmake2713/bin/fontmake", line 11, in <module>
    load_entry_point('fontmake', 'console_scripts', 'fontmake')()
  File "/Users/cosimolupo/Documents/Github/fontmake/Lib/fontmake/__main__.py", line 171, in main
    project.run_from_glyphs(glyphs_path, **args)
  File "/Users/cosimolupo/Documents/Github/fontmake/Lib/fontmake/font_project.py", line 343, in run_from_glyphs
    designspace_path, instance_data=instance_data, **kwargs)
  File "/Users/cosimolupo/Documents/Github/fontmake/Lib/fontmake/font_project.py", line 386, in run_from_designspace
    interpolate_layout_from=interpolate_layout_from, **kwargs)
  File "/Users/cosimolupo/Documents/Github/fontmake/Lib/fontmake/font_project.py", line 443, in run_from_ufos
    mti_paths=mti_paths, **kwargs)
  File "/Users/cosimolupo/Documents/Github/fontmake/Lib/fontmake/font_project.py", line 160, in build_ttfs
    self.decompose_glyphs(ufos, glyph_filter=lambda g: g)
  File "/usr/local/var/pyenv/versions/2.7.13/envs/fontmake2713/lib/python2.7/site-packages/fontTools/misc/loggingTools.py", line 372, in wrapper
    return func(*args, **kwds)
  File "/Users/cosimolupo/Documents/Github/fontmake/Lib/fontmake/font_project.py", line 102, in decompose_glyphs
    self._deep_copy_contours(ufo, glyph, glyph, Transform())
  File "/Users/cosimolupo/Documents/Github/fontmake/Lib/fontmake/font_project.py", line 110, in _deep_copy_contours
    ufo, parent, ufo[nested.baseGlyph],
  File "/usr/local/var/pyenv/versions/2.7.13/envs/fontmake2713/lib/python2.7/site-packages/defcon/objects/font.py", line 224, in __getitem__
    return self._glyphSet[name]
  File "/usr/local/var/pyenv/versions/2.7.13/envs/fontmake2713/lib/python2.7/site-packages/defcon/objects/layer.py", line 260, in __getitem__
    self.loadGlyph(name)
  File "/usr/local/var/pyenv/versions/2.7.13/envs/fontmake2713/lib/python2.7/site-packages/defcon/objects/layer.py", line 177, in loadGlyph
    raise KeyError("%s not in layer" % name)
KeyError: 'l.ss01 not in layer'

I guess the components renaming should be the responsibility of MutatorMath, who is the one actually generating the UFO instances.

Changed rename to swap. Have another look?

Regarding composites, is the current output (after this change) enough for MutatorMath to eventually do the right thing?

That looks correct.
For composites, it’s more complicated.

In Glyphs, if two base glyph names are swapped with “Rename Glyphs”, the composite glyphs still point to the old base glyphs that have a new name. For example if l=l.ss01 is in “Rename Glyphs”, where l is a straight l and l.ss01 is a tailed l, then:

• before swapping, lacute is composed of l + acutecomb (with straight l),
• after swapping lacute is composed of l.ss01 + acutecomb (with straight l).

But if there is also lacute=lacute.ss01 in “Rename Glyphs”, then:

• before swapping, lacute is composed of l + acutecomb (with straight l),
• after swapping,lacute is l + acutecomb (with tailed l).

MutatorMath doesn’t do anything to composite glyphs if base glyph names are swapped, because it has a completely different semantics. Instead of renaming, it replaces the glyph with another from a specified location [master].

I edited my last comment: “it replaces the glyph with another from a specified location [master].”

So this approach probably won’t work, and instead we’ll need to post-process the interpolated instance UFOs?

This is all very confusing, I need more time to understand how mutatormath is supposed to work in this case. I will have another look tomorrow.

Before I forget, I noticed that "muted" glyphs in mutatorMath do not propagate to composite glyphs which reference them. I think we want them to be decomposed. It seems a known limitation:

https://github.com/LettError/MutatorMath/blob/master/Lib/mutatorMath/ufo/instance.py#L402-L404

The Rename Glyphs parameter also switches the export bit and a manually set production name.

Looking at other parameters that can be set for an instance, it looks like we’ll eventually need to post-process the MutatorMath output anyway by rewriting instance UFOs. From that perspective, it might be easier to run the full font through MutatorMath (as today) and instead swap and remove glyphs in UFO, where it’s probably easier to implement the same semantics as Glyphs. Personally, however, I’d like to focus on variation fonts, so I probably won’t be able to spend a ton of time on perfecting instance generation.

it might be easier to run the full font through MutatorMath (as today) and instead swap and remove glyphs in UFO

Wouldn't it be easier to implement the glyph swap/removal at the level of the TTFont instance, rather than in the UFO?
That's what fontmake is already doing with glyphs that have export = 0: it runs the fonttools subsetter as a post-process step.
At least the "Remove Glyphs" parameter could be implemented the same way.
I'm still a bit confused as to how we should implement the "Rename Glyphs" one.

There might be value in a reasonably good Glyphs → UFO conversion outside of fontmake? Not a strong opinion though. Anyhow, it looks like the approach from my pull request won’t work with composite glyphs. So I guess the pull request should be closed without merging.