Applications have been seen building custom decoding pipelines by composing sources and decoders, because they can, among other reasons. Therefore we can expect applications to build encoding pipelines, for the same reasons. Is this really so stretched out?
Anyway, there's even more reasons to do so with encoding, as you very often need to configure the encoder components to fit your needs. I'm confident that having individual components is even more a requirement there.
I'm sorry, what I'm trying to get at is that decoding and encoding are fundamentally different. They are not symmetric operations, essentially.
Decoding is predominantly a matter of turning a multimedia stream in any format into a set of formats that can be rendered. The application never has a reason to care about the source format (and therefore in practice rarely does), and usually doesn't have a reason to care about the destination format either (it just needs to be something that can be fed to GL/X11/D3D/GDI or Pulse/ALSA/mmdevapi). Autoplugging makes sense, since there's generally only one (best) element that can be used to decode.
Encoding, by contrast, requires decision. There are many "raw" formats for any given stream type, sure, but they're broadly interchangeable and mostly motivated by the limitations of downstream APIs. There are many more formats for compressed streams, however, and the selection is generally motivated by things the application cares about (file size, compression speed, patents, platform compatibility). This applies not only to the container but also to the individual stream codecs. You can't autoplug encoders unless you pick some defaults, which may easily turn out to be undesirable, and accordingly DirectShow doesn't try, and I believe GStreamer doesn't try either.
This was a pointless comment originally on my part, because ultimately this is just a distraction. Fundamentally I agree that we probably don't want to embed the whole GStreamer encoding pipeline in one element, but do it individually with transforms and muxers.
In order to fix media source non determinism I intend to add a wg_source myself (could be wg_demuxer), doing the opposite.
Wait, what, why? I know there was discussion about fixing non-determinism by manually reimplementing decodebin, but why does that need to affect the frontends at all? Why can't we just do it inside of the existing parser?