So Al - there's no "outside a coat" wearable then? No bag / outside thingy...
No there's not - at least not a type officially labelled as being such. Bear in mind though that you do have 5 levels of layers already and it's unlikely you'd ever
truly need more than that. The layer names are mostly just there for convenience rather than labelling them layer 1,2,3,4 & 5. You are at liberty to demote / promote descriptions (within some limititions) as you see fit. You are unlikely in this case to want to provide the player with a vest, shirt, sweater, jacket
and coat (that's the order) so you can use the coat as the top layer and call it a backpack, and if a coat is required use the jacket type instead...
If anyone thinks it is really needed, an external carryable like a rucksack or backpack type could be fairly easily built on to the exisiting structure for the next lib release - it is expandable.
The idea of typelib was for it to be a reasonably flexible general purpose add on. Being able to "misuse" the coat type, make it a container and treat it as a backpack object is an example of exactly the sort of thing I was trying to achieve.
You could also give the coat handy pockets in exactly the way you'd make it perform as a backpack - by just retaining it's description as 'coat' for instance
I'm curious if you still use the old 1/2/4/8/16 method (old in the sense of "you were using it last time I looked), or have moved to variables or flags for the seperate layers.
I am still using the binary (1,2,4,8,16) method because it means my tests can often be simplified to using addition inside a test loop, rather than add to the forest of nested IF-THEN statements that typelib already is. Basically I can add together the values of the layers already worn and do one test to check for wearability/unwearability, rather than have to test for each layer inside a test for it's preceding layer or whatever which is what variables or flags would require me to do.

This is also a case of 'if it ain't broke, don't fix it' of course. As anyone who looks back at code they wrote ages ago will confirm, you can often see another way (even a better way) to do things in retrospect.
As I've hinted before to Alex - a SELECT CASE construct would be a Godsend in Quest ASL

Happy new year all!
Al (MaDbRiT)