Defining kinds with tables no longer working?

I frequently use the object duplication feature in my WIP, which is why I need plenty of kinds of things.

So, I’m currently working around this bug (while waiting for the next stable release) by assigning a unique identifier to each type of object. This allows referencing the properties of these kinds of objects in tables and activating them at the start of the game through a ‘When Play begins’ rule.

leather chest armor is a kind of armor. The UniqueID of a leather chest armor is 1.
cushioned leather armor is a kind of armor. The UniqueID of a cushioned leather armor is 2.
dyed leather armor is a kind of armor. The UniqueID of a dyed leather armor is 3.
[and so on]

When play begins (this is the When Play begins - Completion of armor kinds rule):
	repeat with LocalAsset running through armors:
		let LocalUniqueID be the UniqueID of LocalAsset;
		choose a row with an UID of LocalUniqueID in the Table of Assets-armors;
		now the ArmorLevel of LocalAsset is the ArmorLevel entry;
		now the CombatSkillModifier of LocalAsset is the CombatSkillModifier entry;
		now the printed plural name of LocalAsset is printed-plural-name entry;
		now the material of LocalAsset is the material entry;
		now the description of LocalAsset is the description entry;
		now the SocialLevel of LocalAsset is the SocialLevel entry;
		
There are 3 leather chest armors in the Armory.

Table of Assets-armors
UID	ArmorLevel	CombatSkillModifier	printed-plural-name	material	description	SocialLevel
1	20	0	"leather chest armors"	leather	"[leather-chest-armor-description]"	prosperous
2	18	0	"cushioned leather armors"	leather	"[cushioned-leather-armor-description]"	common
3	20	0	"dyed leather armors"	leather	"[dyed-leather-armor-description]"	prosperous
[and so on]

Of course, in this example, the custom properties of a kind of armor (like ArmorLevel or SocialLevel) must be defined first at the appropriate level (“armor”, which is a kind of thing, or “thing” for cross-cut properties).

It’s not as satisfying as Inform’s native feature, but it’s still easier to maintain than a version of the code without using tables when you need many of kinds with many properties. If any of you know of smarter methods, I’m very interested of course.

EDIT : correction of parameter inversion in the rule.