I agree that we should have a standard vocabulary. And I’ve let everyone down by not having a written glossary from the get-go. This should include not just the names of chunks of code, but also of objects inside the system. (key, keyswitch, layer, layout, keymap, etc)
In my head:
- Library or Arduino Library
Some chunk of code packaged according to the Arduino Library definition. This includes every Kaleidoscope Plugin, as well as Kaleidoscope itself. Not every Library is a Plugin. This is a term already used in the Arduino ecosystem. - Plugin or Kaleidoscope Plugin
An Arduino library that is designed to use the Kaleidoscope Plugin API. Every Plugin is a Library, but not vice-versa. It may be the case that Plugins use or wrap Libraries. - Hardware Definition or Hardware Plugin or…I don’t have a good name for this
An implementation of the Kaleidoscope Hardware API that lets Kaleidoscope talk to a specific keyboard or other device. This is an Arduino Library, but not really a Kaleidoscope Plugin, since it doesn’t use the plugin hooks. - Sketch
This is the Arduino term for the main program someone runs on their keyboard. It’s not the term I’d pick if I were starting from scratch, but it’s widely used in the ecosystem, so I think we’re stuck with it. - Core
This is the low-level implementation of the Arduino APIs for a given microcontroller implementation. Every Hardware Plugin runs on top of a core, but some may share the same core.
I’m not a fan of ‘module’ or ‘project’ for things that have official definitions. As I understand it, ‘modules’ are a newish c++ core feature. And projects are things that people work on. Kaleidoscope is a project, each plugin is a project. Sometimes a personal firmware sketch is a project.
For naming things people build for Kaleidoscope that don’t use the Plugin API or the Hardware Plugin API…I’m not sure yet. Happy to entertain suggestions. While ‘wug’ is a cromulent word, it’s probably not the right one here 
Does that make sense?