OK, this seems to be a bug in Inform’s generated parse_name routines. It might not technically even be a bug, just an optimization that’s usually safe, but dangerous when Dynamic Objects is involved.
When a number property is understood as describing an object, that’s supposed to affect the parse_name in two ways, since the parse_name routine serves two roles: it parses an object’s name and also decides whether two objects are “identical” and can be combined in lists (since objects are considered identical only when the player can’t type anything to distinguish them).
When the routine is being called to check whether objects are identical, it’s not supposed to read words from the command line, since this use has nothing to do with what the player typed (and in this case, it’s called before they’ve typed anything). But the parse_name routines generated for “blip” and “bloop” – specifically the parts that deal with the understood-as-describing property – ignore that guideline. This is normally safe since their parse_name routines are unique, and Inform always assumes that objects with different parse_names are non-identical, so they’ll never be asked to distinguish between objects anyway.
However, when you clone blip or bloop, you end up with two objects that both use the same parse_name routine: one which was generated with the assumption that it would always be unique. Inform calls the parse_name routine to check whether the cloned objects are identical, it tries to read words that aren’t there, and you get a runtime error.
So… you can work around this by manually setting the parse_name routine back to the version that was generated for the “thing” kind, which handles this situation correctly:
[code]When play begins:
repeat with N running from 0 to 2:
let new spiffle be a new object cloned from a random spiffle;
correct parse_name of new spiffle;
move new spiffle to the Test Room.
To correct parse_name of (O - object): (- {O}.parse_name = K2_thing.parse_name; -).[/code]