Okay... my thoughts to date based on feedback (AmigaWorld / Amigans Forums) Perception IME - Current plans, perception.library in LIBS: This will be directly accessed from material loaded by locale.library to support the CX Perception in Sys:WBstartup/ the CX tool for the user to access and change any mode settings in perception.library japanese.language in LOCALE:languages/ Working entirely from the original 3.x series development materials so far japanese.charset in LOCALE:Charsets/ I have not worked out what is needed for this part just yet the Language and Charset drivers have been renamed due to comments about this being updated for AmigaOS 4.x to be entirely in English, I have to thank feedback for this jp106 and jp106m Keymaps in Devs:Keymaps/ the jp106 keymap will be modified for a minimal jp106m Keymap Perception will allow support for Modal Keyboards and extended Character sets that are not entirely able to be input using a single Keymap (Japanese and Chinese are examples) the different Character set encodings will be presented and support functions for strings from the perception.library in working with arbitrary character strings. codesets.library is currently being considered as support for this. Polymorph VM - Current plans polymorph.library in LIBS: centralized hub of the framework, nothing else in the framework will patch the OS. any files in LIBS:polymorph/#? modular plugins for various options that polymorph will support these may be loaded from the DataTypes based search option or by direct name convention. One idea is to impliment a full "Virtual Machine" along the lines of Bochs or PC-Task, while another idea is to use a "Wine" styled Operating System Simulation with CPU Emulation. a Smalltalk Virtual Machine is planned as one open source template example to use with polymorph.library to run the Squeak and OpenCobalt Smalltalk Machine images. one of the considerations of this project would be the possibility to deliberately write an application that VMach locks particular tasks of its operation for pushing out across a luster of machines keeping the front-end limited and recovering those threads on other machines after the original host machine is shutdown and restarted after some time. another idea is to make a language specific runtime such as Java, J#, F#, C# or Python, possibly ruby as well... this lends itself as an expansion on how "Wine" with a CPU Emulator would work. all of the above either fall into faking a piece of hardware or faking software, (Windows 8 on ARM Simulation/Emulation mix is also possible?) One other consideration for this library is also lending itself to being possible... and would require feeding structured data through a custom module... Encryption or Compression algorythms based on a virtual processor definition. or even a "movie codec" module of some kind... this has also lent itself to another possibly interesting option. the ability to redefine the encrypting tools definition of the fake CPU during that CPU operating on the data it is fed. instead of having to break an algorythm to force decrypt... the possibility that the conditions that the algorythm requires also are subject to change in fixed ways able to be defined. instead of compressing or encoding data in a different way... the data itself is a program creating the original file stream content using a preset library of functions. and you can NOT rely on those functions remaining static during the life of the program decompressing or decrypting the data it has encoded. I was experimenting with polymorph and such things a little bit using a Classic system, and will be definitely working towards playing with this on an NG system.