I happen to agree with verec, maybe because we both think in Java (?). The libraries and constructs make a HUGE difference for usuability. So I will second what he mentions, and add a few bits ...
Other extremely important aspects are orthogonality, composition, and cannonical form. By orthogonality I mean that tasks, functions, and objects are discrete, sufficiently complete and don't overlap or have side-effects. By composition I mean functions and objects can be combined, like f(x), g(x) -> f(g(x). By cannonical form I mean that combinations are simple and consistent across a wide variety of types.
Composition makes a qualitative difference between TradeStation and Metastock. For instance, EasyLanguage lets you pass a function to a function, but MetaStock does not. That makes writing adaptive indicators difficult in MetaStock, but a snap in EasyLanguage. In EL we simply replace "length" with a function that returns a bounded interval range.
Imagine if this were also true with regard to OHLC quotes. Any quote function could be substituted for actual quotes, and all quote functions could be used on any data series. This includes quote transforms (synthetic data bars), or time compression, or types of quote data (tick, time, volume, range). This is WAY beyond EL, but is a snap when following the same composition and orthogonality rules mentioned.
So, what if the idea is extended portfolios, money management, and other aspects in the trading system? Any function can become a filter atop money management, or the equity curve. Conversely, the function that filters equity curve has the same cannonical form as other functions. This makes the language, libraries and environment consistent, easy to learn, and easy to apply.
I've used these principles in my own trading engine, so I know they are possible to achieve.
The suggestion to ride atop an existing language like C# or Java is an appealing one. I certainly didn't want to invent a new language for trading, and chose to do this. However, the trade-off is always what is possible within the constructs of the language vs. what feels natural in terms of composition. In this regard, widely used OOP languages like C# and Java fall short. Structured language fall even shorter. I'd offer that a natural feel of expression might be more accessible coded in Python, Ruby, or Groovy. Of course, these don't have the wide appeal of more common languages.
It's difficult to strike a good nice balance between ease of use, cannonical composition, and the required language syntax and constructs. One thing that can ease the job of the trader/programmer is using inversion of control (IOC) ... or plug in modules. I think this makes it easier for an end user to extend the system small chunks at a time.
Anyway, just my $0.02. I think these concepts would make an awesome addition to VeriTrader.