Can a spice library contain different component types?
In general, Spice programs use a "card deck" (the term comes from the days when we used punch cards stacked up in a card hopper that would be triggered and read by a computer) to describe a schematic, specialized commands describing what kind of output is desired, and .SUBCKT models. Each card starts with a single letter describing the internal, built-in model category to use. Almost all of the English alphabet was used for various parts, but "X" was reserved for .SUBCKT model "calls." So "R" was for resistor models, "Q" was for BJT models, "C" was for capacitor models, and "L" was for inductor models. They didn't use a lot of imagination here. They just did the obvious.

For everything "not-X", there is specialized internal code that provides an efficient simulation model, with various parameters that can be used to modify that behavior. For example, BJTs have over the years developed a number of improvements to earlier BJT models. And Spice has kept up to date with this. Also, companies will develop proprietary models for BJTs and MOSFETs used in their IC fabrication processes that they don't release but very well may write specialized routines and specialized card processing for in their own Spice programs they develop. The overall upshot is that Spice has grown and improved its internal modeling over the years. And that's as it should be.

Spice will refer to .SUBCKT model code if and only if you use the "X" card type. Otherwise, they use the internal models I just described above. So, if you want a .SUBCKT to be invoked (used) by Spice, you need an "X" card somewhere that names it. There is a whole body of knowledge related to how one might pass parameter values into such .SUBCKT models that I don't want to address here. But .SUBCKT models can be quite sophisticated as well as rather generalized through the ability to modify them via custom parameters to the model.

The original SPICE program didn't include a schematic editor or a GUI. Those things simply didn't exist "back in the day." (Or, where they did, they were exceptionally expensive.) Most modern Spice programs used today include a schematic editor. This editor makes it really easy to lay out a schematic. (But there are NO STANDARDS here.) The Spice program's schematic editor automatically generates the appropriate Spice card deck for you, automatically numbering the connection nodes (unless you over-ride that, manually) for you. Most programs provide a way to see that card deck, when asked.

When you drag out a resistor symbol and place it onto the schematic, you get a visual picture of a resistor. But internally, all it does is remember that there is an "R" card to be generated for it with two connection nodes (numbered "1" and "2", probably.) You don't know which end is which (which is node 1 and which is node 2.) But you usually don't need to know. (It may affect the sign of the current you get, though.) Some Spice schematic editors will allow you to over-ride that "R" type for the symbol, but keep in mind there is NO STANDARD here. It's not guaranteed that all Spice programs will allow you to over-ride the type for a symbol. But if it does allow you to do that, then you can just change it to "X" and reference your model. If you do that, Spice will apply your model to that "resistor symbol." This means you could just plop down a diode symbol and over-ride it with "X" to call your model.

Some programs, like LTspice, allow you to develop or create your own symbols and reference a library file that can contain LOTS AND LOTS of .SUBCKT models inside it and to present you with a drop-down list to choose from. This, for example, would make it very easy to develop a DIAC symbol tied to a library file containing hundreds of different DIAC models. Then, you just drop-down your new symbol on the schematic and select the right model from the drop-down list and the Spice program will do the rest for you. But this behavior is variable. So I can't say if you have it, or not.

LTspice supports the library reference as a special keyword in their unique schematic symbol definitions used to display and operate the symbol. If it sees that special line, it knows where to find the library file containing the models. If not, it doesn't and you have to include it in the schematic, itself.

That's about it, for now.