This would be very nice to have, in both the ServiceStack client AND server. The server part would be preferred, obviously :)

Add better support for Joins and fetching related records.

Add more MQ Adapters, e.g: Rabbit MQ, Amazon SQS, Azure Service Bus, ZeroMQ/nanomsg.

https://plus.google.com/u/0/103098793536210174759/posts/FdZJrFiAWi2

Research optimal deployment strategies for hosting ServiceStack on Linux (e.g. nginx FastCGI/ nginx + reverse proxy / self-hosting inside linux daemon) with the best performance, that best supports CI deployment with no downtime, auto restart/recovery when Mono process dies.

Change ServiceStack to be based on IHttpAsyncHandler so services have the option to be non-blocking by returning a Task<T>.

Provide better support and testing around Android/iOS builds. iOS's AOT restrictions would likely require code-gen to minimize NoJIT errors.

Add first-class integration for hosting on Amazon cloud services (like MS does with Azure), e.g. adapters for Amazon cloud services, docs on automated deployment/hosting strategies.

Add a starter template showing how to get started with a Single Page App with AngularJS + Yeoman + GruntJS working together.

Add optional Strong-named Server and Client NuGet packages so they can be added in the GAC and used inside Enterprise products requiring signed dlls.

An option would be to open the access to Routes.
This would allow to separate the concerns of application workflow in services (describing next operations if required) from route resolution (which could be done in a filter or in the appconfig).

Change NuGet packages so they map 1:1 with ServiceStack projects. So 'Install-Package ServiceStack' doesn't bring in OrmLite and Redis automatically, and we can 'Install-Package ServiceStack.Interfaces' to bring in the minimum dependencies DTO's need.

Support to use @helper not only to call functions in an external assembly (which I think is already supported by SS), but also to call helper functions inside very the same .cshtml template like describied in this link:http://stackoverflow.com/questions/6531983/how-to-create-a-function-in-a-cshtml-template

Much of the existing code implements IHttpRequest and IHttpResponse interfaces and writes complete code for implementing these. That was necessary before the redesign in 4.5 implemented mockable versions of the non-inheritable old HttpResponse classes.

I think it can reduce the amount of code in SS and enable use to not need to use global items like HttpContext.Current.Request which results in - non-testable controllers.

The change to help the above situation I implemented grew out of scope, but thought it worthwhile to explore for a later version.

https://groups.google.com/forum/#!searchin/servicestack/httpcontextbase/servicestack/fpr-QlOH-dY/PFtbLXaW-IQJ

One of the most enticing aspects about ServiceStack is that it is incredibly fast. I suggest that all major aspects of SS (web services, text, ormlite) get thoroughly tested in the upcoming versions just to make sure the code base is as fast as it could be.

Potential speed increase for the Xamarin.iOS and Xamarin.Android ServiceStack clients? See here: https://github.com/paulcbetts/ModernHttpClient

Instead of sharing binary dlls with client projects, provide the option for being able to generate DTO's on the client using metadata from a remote ServiceStack instance. The result to be equivalent to sharing the binary DTO dll on the client, where you can continue to use them with generic .NET Service Clients.

Later add support for generating types in alternative languages/platforms: Java/Ruby/Python/JavaScript/PHP/Clojure in order of interest.

http://stackoverflow.com/questions/12700702/servicestack-ireturn

"In the case where you define your DTOs in a portable class library, you won't be able to use IReturn or the NewApi. Perhaps IReturn should be defined in a PCL in ServiceStack. Just a thought."

Upgrade all projects to .NET 4.0 and change Async APIs on the Service Clients to use .NET 4.0's Task/Future so it can work with C#'s await/async