Eh, not really? It makes atomic parts easier by displaying their pre-assigned footprints, but it also lets* you pick footprints earlier in the workflow while using the same system as always. Seems to me it’s pretty atomic/non-atomic agnostic.
*okay, will let, when that part is done…
You are right about that. (Just tested it because i’m curious.) This is not stored across sessions. 
Well read this last comment by Oliver. (It seems that there is at least the idea that in future the library might go this route.)
But i think it will not happen before the new library format is introduced. (So not in the near future.)
Oliver is in favor, yes. But I said core KiCad developers, not library maintainers 
(That said if the head lib guy is in favor of something, this may influence the devs…)
Dan.heidel,
Did you ever even try this recommendation?
No, that’s insane.
Atomic parts are symbols (KiCAD = component), that have the footprint pre-assigned and where there is 1 symbol per physical device in the symbol library. The footprint and the housing for a device can still be shared.
It also has go ta house internal identification number or the manufacturer assigned.
So two (or more) different devices would be able to share the SOT235 package for example, there would only be one SOT235 package in the footprint library needed (unless you got different footprints for hand/wave/reflow/etc. soldering).
But if you wanted to differentiate the MAX2323 package options in your component library, you would have as many components defined as there are devices you want to differentiate (for SOIC16, TSOP16, etc…).
So if you wanted to exchange a part you would usually define a new symbol (component) and replace it in the schematic.
As for having the 3D model actually resemble the actual physical device down to the text on the package or the colored rings on resitors or the plastic lens coloring for LEDs… that’s not what thi sis about.
We have had discussions/banter about something like that, but this would not be solved by atomic parts, but by some ability of the 3D engine of KiCAD to work with special data that is being stored with the components or can be derived via look-up tables from the values/etc…
In an ideal world i would like to see the concept of a “Variant”.
Say for e.g. you have a CAN chip CAN1234 that comes in multiple footprints with different pinouts. So your library may have CAN1234_SOIC and CAN1234_DFN. But then each of these is available in different temperature rating, RoHS, packaging option, etc. Rather than make a new part for each option you just have to store the different ratings.
This is kind of what the ALIAS idea in KiCad is trying to do but it’s limited to three fields Description Keyword Documentation
If these fields were extensible then the library would be much more useful.
Currently to encode useful data such as MPN, and various rating data, a new copy of the symbol needs to be made. That’s another symbol to then maintain.
Having complex atomic parts will be difficult until this is addressed.
I like the way Eagle does it. A Part is a combination of unique properties (e.g. part number), a symbol and an optional footprint. The symbol and footprint are separate entities and are referenced by name, so can be re-used easily.
I think the new schematic file format goes some way to providing something similar.
Thanks for the clarification Joan. It is pretty much what I do with special library parts, especially if I design them myself, except for the manufacturer no/part no. which sounds like a good idea to include. (I assume one would just add some additional fields for that.) I think it is nice the way KiCad works which allows freedom for both strategies. When at an early stage of a design it is sometimes nice not to have to select which op-amp or resistor package to use. One can have library folders with atomic parts and generic parts, and chose whatever fits the situation best.
Yes! With SPICE being implemented, this makes perfect sense to NOT pick the size/package (or part #) of the part until the current is checked.