Though I know this is an old thread, I'm just stumbling across it now that it has been freshly revived.

If bloat is the driving force behind what is included and what is excluded, then the drive mapping, printer mapping, program group, file and file management, ini and registry functions should all be removed as they are all available via external means--either through COM manipulation, or internal/external batch functions. Removing all of these redundant functions will result in an even smaller version of the .exe and a much more streamlined app. However...

If I wanted to use a language that just provided the mechanism to access these functions without providing any real added value itself, I'd just go ahead and focus on VBScript. The beauty of KiX (at least for me) is that if I want to map a drive, or modify some element of the users environment, or do some file manipulations, it's all available to me in the core language. In VBScript you can't even get an environment variable without the WshEnvironment object!!

The fact that these things are in the core language makes it easier to work with, easier for up-and-coming scripters to get their heads around and in short, easier to be more productive. Removing functionality because it already exists in other libraries or refusing to add additional functionality for the same reason just kills the thing that KiX has always had over other script languages.

For me, if the make-or-break issue was the size of the kix executable, and I was on a network where a 5, 10, or 50K increase in the size of this file would have a cataclysmic impact, then I'd probably avoid KiXtart altogether and focus on a different technology.

But it's precisely because the language itself natively contains real value to the scripting community that it really shines over its peers, not because we're able to shave another 5K off the exe size.

Of course, I agree that functionality can't be added ad hoc, but each new inclusion should be well thought out and be deserved. XML as a data format is not going away and its usage will only increase with time. For the same reason that the INI format is supported (because it makes sense, not because it was written before COM interoperability) I feel that XML should be supported as well, so that KiXtart can maintain that sense of dominance over other languages that are nowhere near as feature rich.
_________________________
Stevie