just like rails, except done in a slightly different way, different
conventions, etc. So let me ask the (possible rude) question that
matters most:
Why should I use this instead of rails?
It's not a rude question at all and you're not the first person to ask, just the first to ask on the ML. Apparently, I am not communicating this as well as I'd hoped on the Web site. 
I am going to have to work on that; I appreciate the feedback.
Or Merb?
Some of what follows is covered at NameBright - Coming Soon but I will try to summarize here some of the key differences.
Waves is thread-safe (like Merb, but unlike Rails); it is DB-agnostic (like Merb) but comes prepackaged to support Sequel (which is also multi-threaded and can convert Ruby expressions into SQL queries).
Waves request mapping ("routing") is very different from either Merb or Rails. It is much more flexible and you can avoid MVC overhead when you don't need it because requests are mapped into blocks, not preset parameters.
Filters are also handled in the mapping, so you can lock down all your controllers from your mapping configuration. You don't have to worry about a secure method accidentally being exposed by a wayward controller.
Example:
# make sure users are logged in before allowing them access to URLs
# beginning with '/admin
before %r{^/admin/} do { redirect('/login') unless session[:user] }
Common patterns can also be packaged into modules for reuse, as is done with the built-in "PrettyUrl" rule sets. I expect to provide more of these (hopefully through contributors as well as my own efforts) in the future.
Waves implements something I am calling "just in time resources" which are MVC classes that are created on-demand based on exemplars. Thus, you often don't need to explicitly implement a model or controller class if it follows a well-known problem. Because controllers are simpler in Waves (they simply return a data object of some kind, essentially adapting requests to models) they tend to be easier to reuse.
Views are also very different. For example, layouts are set in view templates (where I feel they really belong, since they are part of the view), not in the controller, like this:
layout :default, :title => @person.full_name do
...
end
You can also call views directly from within other views (sort of like partials, but there is no real distinction between a view and a nested view in Waves). Waves views are primarily based around Markaby, allowing for pure Ruby templates, although any rendering engine can be easily integrated.
Waves also is hot-patchable because it supports true code-reloading (unloading and then loading, as opposed to just loading a second time, which can leave stray constants and values from prior loads).
Waves is designed to support multiple applications. Each application lives inside its own module, so they are completely separated. This makes it easy to reuse entire applications (although only one "master" application can provide the mappings and configuration).
Finally, Waves may look on the surface somewhat similar, but beneath the covers, almost every aspect of Waves is designed to be extended. Even the dispatcher can be extended or replaced entirely.
There's more, but hopefully, that helps a bit. I will try to spell this out a bit better on the Web site. Thanks for the feedback!
Regards,
Dan
