Number 18 is questionable to me.
18. By their nature, rulesets and rules are read-mostly objects. A standard way to load-on-startup, refresh and lazily load these objects would help the run-time performance of a rule engine whilst ensuring portability.
In a RETE rule engine, the rules are light weight and really do not take much memory. The scenario described by #16 is supported by the concept of a rule module in most of the current commercial engines.
16. The ability to execute a set of rules as if I was winding the clock back to a date in the past is a common business requirement as is the ability to report on what rules where executed for what products at a certain point in the past. This time-variance functionality is very useful particularly for industries that are heavily regulated or that need to back-date for example an order or a trade.
I like the idea of supporting some standard modeling language. Wether it is UML, Schema, DTD or RelaxNG will be a subject of debate. #3 can be implemented in a simple way and doesn't necessarily need to be part of a rule specification. I can see cases where each mode is desirable, but I would rather that be driven by the application development.
3. Under certain conditions, we do not want certain rules within a ruleset to fire. A rule firing may depend on the results of rules with a higher salience. One could argue that this logic should reside in the rule itself but this would then tie the individual rules together. This logic should remain as a separate orthogonal aspect. Id also like to be able to execute a rule instead of another rule similar to the way instead of triggers work in Oracle and SQL Server databases
The reason i say this is if we look at how CLIPS implements salience, and conflict resolution, salience has a very specific meaning. Most likely I don't understand the goal of #3.