Hi Raoul,
A library part has a default parameter list, this is the one shown in GDL editor. The current parameter list that the user sets up is stored in the placed objects, not the library parts. The library part's default list can be loaded into the placed object's in the settings dialog, as a whole, not selectively.
As runxel suggested migration can (and should) be used to handle new and deleted parameters of a library part, keeping unchanged ones.
During loading a library, placed objects' library parts are identified by a GUID, not their names. Different versions of a library part have different GUIDs. Migration can happen between different GUIDs, the name of the library part is not important.
The GUID is not editable in the GDL editor, but the Save As... dialog has an option Create New Library Part when you save to a file, which creates a new GUID. If you work with embedded libraries, giving a new name creates a new GUID. If you need to migrate many objects, it might be easier to use LP_XMLConverter and edit the library part metadata directly in an external editor.
Backward migration happens when the plan is saved as a previous version. The master + backwards migration script is run.
If the script contains a SETMIGRATIONGUID command, the GUID of the placed object is replaced, opening the plan next time will look for the previous version of the library part.
During migration the previous version's parameter list is not known, but parameters can be added using the (counter-intuitively named) NEWPARAMETER command. Any parameters that are not in the default parameter list of the previous version will be deleted during loading.
Forward migration happens each time a library is loaded. AC looks at the migration table of each library part, and if it finds the GUID of a placed libpart, the master + forward migration script is run.
It can access both the old placed objects parameter list and the new libpart's new parameters' default values. Deleted parameters can be accessed using DELETED_PAR_VALUE, kept parameters can be used by just writing their name, new parameters' defaults are accessed by writing their name. PARAMETERS command can be used to change parameters, but you can't rely on the parameter script's mechanisms (multiple run, GLOB_MODPAR_NAME, VALUES, RANGE).
If the script contains a SETMIGRATIONGUID command, the GUID of the placed object is replaced, the master + parameter script is run on the replaced object.
Another type of forward migration is when the migration table entry has the AutoMigration option. This doesn't run the migration script, just replaces the GUID and merges the old parameter list into the new (discarding deleted parameters, setting default value for new ones). We use this only to change the names of library parts, but might be good for your case when the new parameter defaults are OK for any placed object.
SETMIGRATIONGUID "" also refuses the migration (in any direction), the GUID won't be replaced and the object will continue to use the same library part.
These are the outlines, ask if you have further questions.
Péter Baksa
Software Engineer, Library as a Platform
Graphisoft SE, Budapest