the features you describe are generally supported by the system and more-or-less-easily “enabled” in the scripting environment.
(NB: code examples are not tested/complete, only for illustration)
While running MLR on norns, can it resample itself?
mlr.lua doesn’t expose this by default, but the engine routing matrix supports it:
engine.play_rec(2, 1, 1.0)
output of voice 2 is now sent to input for voice 1.
since you mentioned panning on another thread: in MLR the panning of each voice is defined by
engine.play_dac(1, 1, 1.0) -- voice 1 -> L output level
engine.play_dac(1, 2, 1.0) -- voice 1 -> R output level
-- &c
and certainly this could be modulated.
Can norns set audio recording to be triggered by an incoming audio signal?
sure, something like
local isRecording = false
local threshDb = -20
poll.set("amp_in_l" function(x)
if x > threshDb and isRecording == false then
isRecording = true
engine.reset(1)
engine.start(1) -- assuming that voice 1 is "armed" already
end
end)
Can you send Osc out of norns
yes: OSC.send(host, path, args)
(of course the other machine needs to be on the same network… that aspect is potentially more annoying)
If you want a parameter to change over time, for a simple example: the sweep of a filter, is this something that can be coded with lua?
sure, though fast modulations are better handled on the SC side. many engines provide slew, ramp, and/or envelope elements for many or all synth parameters. “automation” could mean a lot of things; recording sequences is pretty straightforward since you can access the system time from any event handler.
certainly,
local param1value = 1
local param2value = 10
function enc(n, delta)
if n == 1 then
param1value = param1value + delta
param2value = param2value + (delta * 10)
engine.param1(param1value)
engine.param2(param2value)
end
end
(param1 and param2 are both swept by encoder 1, param2 sweeps 10x faster. you could go crazy and have an array of 100 arbitrary mapping functions triggered on each encoder update.)
passersby for example is a script with some LFO and control routing abstractions. Ack is a fully modular engine. but modular patching by menu-diving a 128x64 screen is not a normal idea of fun. (even by the standard of synthesis nerds.) strong argument for text as better interface.
i know you say you aren’t interested in programming. but this is a small object with limited UI real estate and expansive functionality. so the strategy is to provide powerful scripting environment for UI customization. IMHO the system lends itself better to small focused things than to kitchen-sink applications. (my kitchen sink may not be your kitchen sink, and the limited UI bandwidth means dense functionality comes at the cost of intuitive use.)
its a computer; “yes” for some value of “-ish” 
i’m admittedly suprised to find the demos using “polysub” described as sine-like. they sound juno-ish to me. the engine uses antialiased primitive oscillators (xfade between sine,triangle,saw,pulse, with variable pulse/saw width), plus noise, through a modelled moog filter, in classic(/boring) subtractive style.
i guess the “cleanness” is a musical choice. (though also, there is no attempt in polysub to model drift, saturation, &c - this could be a fun experiment for someone.)
other engines use FM, feedback, wavetables, SVFs, gendys, &c. the available palette in supercollider is as varied as it gets. (but again palette != style)