> 	even if we use charmap, encoding module won't be that big i guess.
> 	data (the conversion table generated from charmap) will be big though.

But the charmaps file is certainly one of examples that current 
implementation is not complete, isn't it?
(Also, there should be a way to extend LC_TIME, LC_COLLATE, and other 
 capability, too.)

More importantly, we should have the way to extend locale dynamically
(like Solaris and other OSes).
That is the problem which I'm worrying.

> 	also, since charmap is a static table (not conversion formula)
> 	there's no reason for it to require different encoding modules
> 	per different charmaps.

Charmaps file cannot cope with stateful encoding.
So, if there is other stateful encoding, dynamically loadable encoding
module is needed.
(LC_TIME and LC_COLLATE needs dynamically loadable modules, too.)
--
soda