In recent versions of Blender we've changed logic in a way that only selected tracks are converted to mesh. This way it's more useful to do partial reconstructions, or to ignore some "helper" tracks from the object.

Full backtrace:

@Philipp Oeser (lichtwerk) Here's the file, all pared down from the original, but has the motion tracking data, and the working constraints.

with the old dependency graph objectsolver_evaluate() is called on file load but not on playback
@Sergey Sharybin (sergey): could you have a look? If its an easy fix, give me a hint, I'll do then

not happening with the new dependency graph btw. ( when you start blender with blender --enable-new-depsgraph )

I can confirm its not working in the provided file.
First findings: if you add another bone constraint in the constraint stack [e.g. copy location] the object solver constraint on the bone will start to work.
(It doesnt really matter what kind of properties you set in the 'other' constraint -- could be inactive/hidden even...)

Close as requested.

Well, on the fresh head, it seems that I want impossible thing. I should rather render scene in 20% and then Composite it with 100% resolution, or stick with File Output. So close it down.

I don't see difference between viewer node and file output. Only difference is between render result and file output, but that's because using lower resolution for final render acts like a "canvas" thing. It does not scale anything up or down. For that you can use Scale node est to "Render Size" mode.

This issue was already fixed, see T51850.

This isn't really a bug, Filter Tracks and Clean tracks are using different ways to identify and operate on outliers. Clean Trackswill use Frames, Error and operation (Select, Delete Segment, Delete) from the tool shelf as initial values for operator settings (which you then can tweak in operator redo panel). Filter tracks will only select tracks with the the track threshold coming from operator redo panel.

Yes. Same here on OSX 10-26 build.

In the middle of something else atm, will have a look later.

I accidentally found that there is one very important factor that I missed: sequence should start from any frame except 1st.
There is archive with simple sequence and two blend files: one starting from 1st frame, other from 28th frame. The latter one demonstrates this bug.

I can not reproduce the bug on Linux.