This is a window manager (WM), built on ideas of another (excellent) WM, Ion. Fundamental principles of both Ion and TrsWM are reduction of manual window positioning and possibility to completely manage windows using only the keyboard. Ideally, mouse could be optional and supported, but neither main nor required method of manual window management. Below I will briefly lay out some thoughts and ideas which motivated me to start TrsWM development.
1 Easy extensibility and ability to build lightweight and useable environments for systems with limited resources, as well as more featureful (or just better looking) setups, if sufficient resources are available. TrsWM was designed from the ground up as a set of modules, and many architecture features are geared towards easy addition of new modules and their independence from each other. This goal is largely achieved - main executable contains only small set of service functions, totally unrelated to functionality and behavior of the system built using this set. All the "window management" code is in the modules. Ion also supports dynamically loadable modules, but "pluggable object event handlers" technique, while very useful and extensively used in OOP, sometimes is less than optimal for WM, and some interesting features are difficult to implement within Ion's framework without modifying main WM's source code.
2 Window layout policy. Ion's basic idea "screen is split into non-overlapping frames, each frame contains >=0 windows, each window's size is <= size of the containing frame" is genuinely simple and beautiful, but often is not sufficiently versatile. TrsWM utilises somewhat different policy - "Every window is placed into the corresponding frame, frames could be of different types, frames with equal type do not overlap". This policy, IMO, is better targeted on maximising usability of modern complex software suites.
3 Handling of position and size requests coming from client windows. TrsWM generally sticks to Ion's policy "window will have no more space than available in the parent frame", but could be set up to satisfy such requests from selected classes of windows. Sometimes software developers know better why their programs need this space. Well, two previous reasons are partially obsolete with introduction of "floating workspaces" in Ion, but (IMO, again) mixing two completely different policies would sometimes lead to user confusion.
4 (Reasonable) integration with a scripting language. TrsWM was started as a project when Ion was using its own, quite simple but sometimes not flexible enough configuration format. Choice of Lua as a scripting language extension proved itself right. Since that both WMs are using Lua as configuration (and more) backend. I want to say, however, that current Ion development path - "rewrite WM using Lua" do not seems entirely correct to me. Back in time, Sawfish was almost entirely written in some kind of Lisp, and, while absolutely tunable and easily modifieable, was not very well suited for usage on slow systems due to unacceptibly slow (for WM) execution sometimes.