SMuFL clarifications

Hello,

I'm currently working on adding SMuFL compliance to GNU LilyPond as a
Google Summer of Code project. However, SMuFL's published specification and
the example fonts left me unsure about a few things. Here's a list for now;
I may have more later.

   1. I noticed that, while Bravura has many alternate and ligature lookups
   in its GSUB table, Petaluma has none. Both, however, include JSON files
   with stylistic alternates and ligatures. Is it reasonable for a
   SMuFL-compliant program to assume that the JSON metadata file includes
   everything that might also be specified through OpenType features? (In
   other words: can we drop OpenType support without risking missing any font
   features?)
   2. From what I can tell in the Bravura font, the stylistic alternates
   are spread across 'ssXX' subtables, and then only those that aren't part of
   a styleset are placed in the 'salt' subtable. So, when a stylistic
   alternate is recommended, for example E0A0.salt01, what significance does
   the number 01 have? Does it only determine the orders of alternates in the
   JSON files?
   3. (This one depends on the previous question, I suppose.) Emmentaler,
   LilyPond's default font, which I plan to convert to SMuFL, has a very
   different set of alternates from either Bravura or Petaluma. Must I stick
   to the recommended 'salt' number for a particular glyph's alternate (e.g.
   salt03) if it's in the specification, even if Emmentaler doesn't have
   versions of the glyph's lower numbered recommended alternates (e.g. salt02,
   salt01)?
   4. The specification for the "glyphsWithAlternates" JSON object states
   that "Font designers are encouraged to use a consistent naming scheme for
   alternates." Does this mean consistent within the font, or consistent
   within the entire corpus of SMuFL-compliant fonts?
   5. The SMuFL specification recommends creating two versions of a music
   font, one for scoring and another for text. Would it be acceptable to
   package these two fonts under an OpenType Collection to avoid file clutter?
   6. In LilyPond's current in-house font format, some .scm metadata files
   are embedded as generic TTF/OTF tables, providing an easy way to bundle a
   text-based file in a low-level readable format. Is it acceptable to embed
   the JSON metadata file in that sort of table to avoid file clutter? (Or
   might that option at least be explored in future revisions of SMuFL?)

Thank you in advance for your help,
Owen Lamb