(disregard latest commit, involving very experimental/wip/poc regarding text support for OscInput, i wanna keep this change focused on OscOutput), switching it to draft, as i might be noisy in between)

That's an excellent PR! Most of my comments are nitpicky about code-style and conventions.
But there are three things that should be done:

Thanks ! :)

The Op should implement the Dispose-Pattern and probably disconnect when disposing.
(If not, it might happen that the op keeps an connection open).

done.

Another problem might be that too many open connections will lead to performance
issues. I'm not sure if this is true but OscInput uses a shared OscConnectionManager to
pool and reusing connections. Although this optimization might be quite involved.
I think we can live without that here.

The conManager is built with a server purpose in mind, and won't be much use for us here.

I'm not sure a threaded model would help us in this context, as there's no error check on the OscRug.foobar.Send() (we're UDP), and a given operator should address its whole traffic (all distinct IPs/port/location)

We can check a later stage, for a threaded model, if we get performance issue, but i think we're fine here.

On another, perf-related note, the operator gives a tiny glitch once in while, but seems to be related to the refresh rate of Tooll (and phase with touchosc frame rate (where you can't disable vsync) : it completely disappear when I disable vsync (in tooll) and it stays well under 1ms frame-time).

This is a general issue with OSC client (TouchOSC does that too (this is why many standalone sequencer/drumbox were attempted and failed (15ms is barely noticeable for eye, but sound like a clumsy drummer for a sequencer)

Please implement IStatusProvider. This will show a warning icon whenever the op
has a problem (like a missing connection or an invalid IP address). Check [AbletonLiveSync]
for an example.

Done!

(edit: quotes readability, bis..)

Awesome!