Building a Racket client for SC

Hi! I'm building a Racket client for SC and I have a few questions about
design, because I'm at a point where I might regret some choices later.

So far, I've built the part about parsing .scsyndef files into a client
side representation and viceversa, from a client side representation to the
binary scsyndef format. I've assumed you send synthdefs via OSC using more
or less the same binary representation. I'm happy with the result, but I
don't know to what extent I can simplify things:
· In the scsyndef representation, ugens have a list of outputs specifying
their rate, like [kr kr kr]. First of all, is there any case where you
would have 'kr and 'ar outputs from the same ugen? And second, what are
some cases of ugens that have multiple outputs? Because so far I've only
seen the Control ugen that SClang generates automatically for the synth's
parameters.
· Because of this, ugen inputs have two indexes, one for the input ugen,
another for which output of that input ugen, which seems to be always 0 for
the reasons above.

Also, a few stylistic choices I'm pondering, tell me if there's something
wrong with them (I haven't used SC for a couple of years). My philosophy on
this is mostly about making it easier to use, more accessible, but always
leaving some option to do things in a more technical fashion:
· instead of having to declare an Out.ar at the end of each synthdef, the
last expression will be automagically wrapped around one and an out
parameter will be added to the synthdef before sending it to the engine or
writing it to a file.
· for this reason, synthdefs will have a rate (ar by default if
unspecified, but kr in case it's something you would rather output through
a Out.kr)
· ugens like Out, SendReply, XOut, etc... will be classified as sender-ugen
subclass. Those won't be wrapped around an Out.
· no distinction between synths and groups.
· I guess there's no way to make all parameters susceptible to modulation
other than creating an In ugen for all of them, but that might introduce a
performance penalty. The other alternative would be making synthdefs and
calling them on the fly, but that wouldn't be very efficient in some
contexts. In this respect, I prefer Puredata's flexibility and the fact it
makes no distinction between ugens and synths.
Of course, that also has to do with the fact that Puredata uses what I call
'static polyphony': if your synth is gonna use a maximum of 9 voices at the
same time, you just create 9 instances of such synth and leave them there,
even if silent. This way, creating a synthdef on the fly that automatically
includes an In.ar for the modulator is feasible.
However, the 'dynamic polyphony' that I think is more common in SC culture
(where you create and kill synths for each note) imposes restrictions on
flexibility to make sure the calling of synths is fast enough.
One advantage of focusing more on 'static polyphony' is that it would let
me do away with the group/synth/ugen distinction that always bothered me so
much, using instead Puredata's boxes-within-boxes representation on the
client side (later transformed under the hood into a more Sc-like
representation).