The if at all part depends on if it will be doable without too much
pain to support both celt-0.5.1 and celt "1.0" in the same binary.

Should work without major trouble, the symbols exported by the shared
library have a versioned prefix.

This is important to us as we care a lot about protocol
compatibility.

Are you seriously telling me that you have no plan whatsoever for how
to transition from a random snapshot of an experimental codec,

We can transition just fine. server + client can signal supported
codecs using capabilities. We can even support something completely
different such as ogg or mp3 (once the patents are expired). We just
don't want transition from one random celt snapshot to another random
celt snapshot and the next random celt snapshot next year.

> But so far, all have accepted this _is_ an experimental

codec, and they must be prepared to move with it. The interested app
maintainers and upstream discussed this, and we settled on 0.7.1 as the
next stable epoch for things that want broad interoperability.

We settled on 0.5.1 for interoperability.

/me figures the latest celt version is 0.9.1. The web page lists both
0.5.1 and 0.7.1 in the "provided mainly for historical reasons" section.
So you picked a random snapshot too, just another one.

Are you aware there may never be a celt 1.0? We have roughly 2 years
from today before any version of spice will have a chance to be even
considered for the next Debian stable release - and if things go as
expected, it will not include any version of celt at all. There will
instead be a new (and standardised) codec that was spawned from it and
merged with other codec work.

When celt merges with others and gets renamed in that process -- no
problem. Once the bitstream format is stable we'll happily support it.
But even then we will not drop celt 0.5.1 support to maintain
compatibility with older installations.

If that means an update to the spice bitstream protocol, now might be a
good time to explore one.

Isn't going to happen.

If you don't want package celt 0.5.1 -- fine. You can patch your spice
server and client to just not signal the celt capability, and they will
interoperate just fine with everybody else using raw uncompressed audio.
But IMHO it would be stupid to not support audio compression in your
spice packages. That is your call though.