Main Goals of the subsystem is to:
A.utilize resources wisely, reuse threads,make permanent synchronization events work,research by reading and coding and testing and recoding and then retesting..repeat. also making a easily adjustable environment and dynamic environment capable of acting suitable to the user's need without much work by him/her.
B:
Act as either a intercept between Win32 and csrss or as csrss. there are various ways to do this Ill discuss them very lil cause there very well documented everywhere..(books,web,ect..)
but the ways i can think of is
1. replace CsrApiPort with our port handle.
In my opinion this is lame...and incomplete.. but combined with 2..
2. replacing all string ascii and unicode that contain CsrApiPortName in with my PortName.doing it this way has various benefits that should be obvious to some.. if I replace all the Name References then I can become the sole holder of a csrss API port Handle..essentialy like becoming a bottle neck...
This can be done in ntdll by hotpatching or binary modification/wfp bypassing or dynamic conditional runtime hooking..
3. the 3rd way is to become csrss..ie Load Before csrss and the win32 subsystem, similar to the effects of "BootExecue" option but a bit more proactive and we have the chance to do preinitialization of data and apply the Patching Engine's instructions located in the Registry
I would love to hear any of your ideas..other then the ZwRequestWaitReplyPort hook one, that I didnt mention above
C:
Provide a subsystem that uses a Plugable shared section between the client(win32 Process) and the "server" subsystem..
Plugin's include but are not in any way limited to
1. Software BreakPoint Manager
2. Patching Engine capable of generating hookhops to bypass malicious hooks,Function Tree Mapping also to avoid hooks,Dynamic Hotpatching of ntdll functions that allow it, also uses multiple hooking implementations to obtain the same effect but be usable under various circumstances. Hooks can be placed in alot of locations, and the effects can be emulated or directly implemented, emulated by using NtRead/WriteProcessMemory (old school..) or directly implemented by Queueing a APC to a Client Thread currently "listening" and then connect to that thread..this should instantly execute the APC and viola effect achieved. more on this in the up and coming documentation release... sometime in the near to late future..
3. Pre-Runtime Branch Disasmbly. Alot of credits to darawk on that one(no real help from him but his code was all the help I really needed, as im using his IsEndPoint function used in GetFunctionLength,albiet somewhat differently, but still the base is his..
4. Runtime Stack Snapping and Context Capturing... (some code on this in next release of the server) 1.02a
many more plugin are going to be implement..
(currently try to make WinSock work in Native Mode..)
B.2:
Implement a Custom RPC mechanism that is controlable from either a gui or a console application to communicate with both client and server.this can be done by stripping out the HEADER of PORT_MESSAGE and rewrapping it in a Custom structure.. and then create functions the work with the structures..
the plugin framework will have to be implemented for dynamic subsystem behaviors but that feature is secondary now..
C:
lastly is to Provide a stable approach for NT/2k/XP and maybe even 32/64 bit vista,but that requires alot more time, and quadruples the amount of research.., So I am just focusing solely on XP(sp2 ~ sp3)..
To keep track of the posts in all our 
