Maybe you could add modding API, so when mod comes out, we won't have replace whole executable? Instead we would add to powder toy directory/mods dll/so/dylib file and in PT options we would be able to turn on/off different mods. This way we would be able to use several mods at once so mods author won't have to implement already developed elements, instead he/she would point to mod that have it suggesting turning it on.

Yeah, but having X powder toys installed and wondering which exactly one has elements I need isn't great either.

Plus it would give main advantage to modders as they won't have to reinvent wheel. You need SuperUberFluid from my mod but you also need SuperUberGas which my mod doesn't implement, but other mod do? Go install both mods and enable them in config.

Well, every mod will be DLL file (like winamp plugin) and will have functions that would be executed by main app, like logictick() or draw(). From API side, there will be function like getElementsList() that would return array of elements that are in game (both modded and vanilla) and good written mod would check if element it want to react with exist on this list, then do reaction.

Well, currently powdertoy is doing things like this:

doLogic();
doRendering();

With mods it would do

doMainLogic();
doMainRendering();
for i in mods //quiet, I know C doesn't have such construction, that's just example
{mods[i].doLogic();}
for i in mods //quiet, I know C doesn't have such construction, that's just example
{mods[i].doRendering();}

Every mod would mind it's own particles and check for nearby if they have changed, then make reaction. Mod will be able to spawn any particles if it need to (e.g. WATR contacts with Gas making particle from mod A and upon contact mod A deletes WATR and spawn UberGas from Mod B in place of WATR, of course first checking if there is UberGas in getElementsList()) from modded ones and vanilla given they're present in getElementsList().