Nested Hierarchical Models for the Missing Parts

From LTwiki-Wiki for LTspice

To recap the process: First, create all the pieces of your new library (including text fixtures) as graphical hierarchical components. All development is done graphically with schematics rather than netlist text. This alone greatly reduces the chance of making mistakes. As you noted, LTspice will create mistake-free symbols for you, which then are very easy to open and edit graphically to improve their aesthetic appearance if so desired.

Hierarchical symbols include a popup parameter line to allow easy, correct parameter passing with the opportunity to modify them on an instance by instance basis. Note that parameters and functions defined within a subcircuit are local in scope to that subcircuit (and any lower level subcircuits), but it is possible to declare global nodes from within subcircuits. (I haven't used it much, but I also believe LTspice allows simulation commands to be placed within subcircuits for test purposes if run standalone. These are then ignored if run as a subcircuit within a hierarchy.)

During this development phase, LTspice forces you to keep all your work together in a single folder where it is most convenient to keep track of (later on, once the library has become mature and stable, LTspice provides the editing tools to effortlessly convert the library to netlist text, after which the library and symbols can be copied to standard folders and used by all schematics if you so wish).

As you noted, the conversion process is simplicity itself - just view the top level netlist, then right mouse button click within it to open a menu that offers the choice to edit it as a text netlist using LTspice's built-in context highlighting netlist editor. All the hierarchical subcircuits appear correctly as text subcircuits, including any parameter passing statements. Just remove the top level simulation commands if you wish (I believe this isn't even necessary as I recall that LTspice ignores them if the library is called as a library rather than an include file), make sure the first text line is a comment (a SPICE requirement for libraries) and save your new library. What could be easier and is there really any reason not to use this method?

Turning a Hierarchical Symbol to a Library Symbol

In a symbol editor you go edit -> attributes ->edit attributes, put X into prefix, and SpiceModel (file)name (without extension). It then turns yellow, and you have a functional .asy file that works fine with a model library.

Note that there are several useful end forms that are possible (not just the auto colored body form directly above). The symbol can have a link to the library embedded within it and it is possible to configure it to allow the user to link it to one of a variety of different components via a drop-down pick list within the symbol itself. The symbol may be configured to lock out editing and possibly other variations.