Well, a simple scripting language isn't unreasonable. Also, it could reduce the size of the program and the source if it is custom coded.

Pros: Easier to code new elements
Beginners are more aware how to.

Cons: Time
A few thousand lines of code.

Maybe devest8a should update the first post to include a list of ideas and a list of pros and cons. From the list of pros and cons we could remove cons that we find way around.

Pros:
-Dynamic Element Loading increases flexibility of the powder toy platform
-Allows use of elements from forks and mods to be loaded and used on the standard powder toy
-Updates will only be necessary for glitches and engine improvements
-New elements are expected from updates and are what excite users(mainly), greater interest will arise from the rush of elements
-Will allow a great rush in the advancement of technologies in powder toy(processors, reactors, etc)
-May generate interest of developers in the platform after they create their own elements

Cons:
-Will slow down the powder toy(if interaction rules are used)
-Will increase size of powder toy
-*MAY* be buggy, require fixes
-Slower load times(especially with slow connections)
-Major rework of engine in many places to allow this
-Will complicate development, requiring developers to learn a new language

Personal Ideas:
1) Load element traits into variables to increase access speed.
2) If element interaction rules are implemented, upon load they will be loaded into powder toy(cached), lexed into tokens(and any other preparations for interpretation), therefore they will be much faster when controlling elements
3) Possibly still allow hard-coded elements + interaction rules(best way is to load elements the same way they are when gathered from server, minus networking), that way complex rules can still be run efficiently.

Catelite
The only problem with what you seem to be suggesting, this would be one hell of a rework my friend(I'd think to get this thing stable might take months).

I have other idea, with powder toy there will be directory with 666 headers, every header have own element, for example :

PT_DUST
POWDER
FLAMMABLE
22 /*TEMPERAURE*/
3 /*WEIGHT*/
EXTRACODE = /*written in powder script */

so modding will be very easier

Powder Toy will be find headers in this directory and read them

Really? Had to use that number?
On topic: That would mean we would have to include EVERY header. Making the code take up that much more space. And. That would actually be sortof useful if you think of it. Because it's simple.

Summary:
Pros: Easy, anyone could do it.
Cons: WAY too much space taken up, the time to set it up like that.

YEESSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

I could see that. A ROBLOX admin script is over 1000 lines just to have someone say "kill/all" and kill everyone. So that type of scipt would be a sinch to use and to code new elements.