Here is a medium-sized rant for you.

> laziness is a bad thing

Laziness is an important motivation behind many best practices in software development. For example:

• "I'm too lazy to write this functionality which already exists" - use a library, which saves time and effort and will probably have a lot fewer bugs than anything I write.
• "I'm too lazy to type / copy and paste the same thing again and again" - DRY, refactor.
• "I'm too lazy to test this manually every time I change it" - automated tests.
• "I'm too lazy to think about what this code does whenever I need to edit it or use it" - use comments, and descriptive variable and function names, to reduce the amount of thinking required.
• "I'm too lazy to check this code" - use static analysis, dynamic analysis, automated tests, and compiler warnings to catch most of the problems, and then do a bit of manual code review.

Laziness is a good thing if it means "don't make development unnecessarily difficult". If development is more difficult, it takes longer, and people are less likely to want to do it. One of the reasons I haven't been doing much work on the official version recently is because, even without property setting elements, there's a lot of things which I want to change / reorganise / improve but due to compatibility I can't do so without a great amount of difficulty.

For example:

• surface normal finding for photon reflection+refraction is a bit buggy (which I wrote a fix for a few years ago, but the fix makes photons reflect+refract at slightly different angles)
• the formula for photon refraction angle is wrong
• powered elements activation speed depends on particle order
• the way particles currently interact with air pressure/velocity depends on particle order and prevents air update being done in parallel with particle updates
• custom LIFE rules (consistent conflict resolution (which life type to create if more than one is possible) while preserving legacy behaviour is difficult)
• linked list pmap (but some saves with stacking rely on only the first particle at each coordinate being visible to other particles)
• PSCN-NSCN creating a spark in response to photons should work when hitting either PSCN or NSCN, not just PSCN
• a defined priority for electronic elements if multiple inputs occur simultaneously (e.g. PSCN and NSCN on the same frame for SWCH) instead of particle positions or particle order determing what the result is
• a faster spark cycle
• the ability to extinguish coal
• explosives that don't explode faster left-to-right than right-to-left
• getting rid of all particle order effects as much as practical
• improved combustion (take more than one frame for a pixel to turn into fire, and more sensible method of determining resulting temperature change)

Property setting elements would make the situation even worse. I do not want to make TPT unnecessarily more difficult to maintain - if I did, I'd write everything in the same style as Simulation::find_next_boundary().

Also, it's not just me that thinks maintainability of TPT is already a problem:

[14:06:04] <savask> Ximon: Probably there is a way to make TPT multithreaded after all, isn't that great
[14:06:15] <Ximon> woo
[14:06:41] <savask> Ximon: But you will never see that implemented because TPT is too hard to maintain. HA!

2. See a few pages later, http://tpt.io/.255512

In addition to the reasons in that post: part of the fun of Powder Toy is in the challenge of working out how to build things, within the constraints of the elements available and the functionality available from those elements. This means there do need to be limits, otherwise there is no challenge and therefore much less fun. This is why, for example, FILT does not have a binary addition mode - because it would make things much too easy. Of course, features/elements are sometimes added to give less convoluted ways of doing things, but there are still limits to what they can do.

(I'm aware there are other sources of fun in TPT, such as blowing things up, or watching cities melt when you drip lava all over them, or looking at the complexity of other people's saves and how well they operate, but for actually building things there needs to be a reasonable amount of challenge. Otherwise there is barely any satisfaction in overcoming the challenge, no feeling of having beaten the restrictions and having achieved something.)

If you want to be able to make a program do absolutely anything you want without any limits, then programming might be a better choice than playing a physics sandbox game.