Audio/Video out of sync in rendered video, but not in VSE
I was asked to take a look at this post. Codecs can be rather puzzling to diagnose from a distance, but it does seem that some information can be offered.


  This problem seems always to pop up when then input source video is
  "mostly static", i.e. when the change from one frame to the next is
  miniscule (e.g. a screen recording). I should also add that I record
  the videos in question using a lossless codec (FRAPS or lagarith).


The “mostly static” comment here is interesting. This does indeed sound like an I versus P / B frame issue, as the “mostly static” frames would be subject to many more instances of P / B frames. While I am unfamiliar with Lagarith or FRAPS, I would be extremely surprised if a non-GOP codec had this issue, as your solution hints toward.


  Why can Blender (or its version of libavcodec) apparently correctly
  decode and show the video in the VSE, but not render it correctly? Is
  the decoding in the VSE done differently than in rendering?


The VSE is using certain techniques to display the video that, when decoded on a shot by shot basis for rendering are different. This is why non-GOP codecs are more robust, or time code indices will yield more consistent results. This is also why most always-online NLEs will transcode upon ingestion; to avoid the codec problems as well as try to reduce the always-online image degradation issues.


  What version of libavcodec is used in Blender 2.74? Is the
  implementation of e.g. lagarith faulty in this version? If not, then
  why does Blender mess up the rendering?


FFMPEG's version was a bit nasty on some platforms as it previously used a bundled version on some while on others it used a local version. If you check the ffcompat code, you can see many version checks to support generic versions of FFMPEG.


  It has been suggested that one should use "Blender-friendly" codecs
  for compression. Which lossless codecs are known to be so?


The easiest way to avoid all of the codec mess is to rely on still frame intermediates. If you must for whatever reason rely on codecs, you are likely going to be constantly faced with these sorts of issues unless you manage to coax one of the codecs to behave under generated timecode indices. I would also speculate that FFv1 should be a reasonable choice to test and put under duress, given the nature of its design. If you try FFv1, it would be interesting if you reported your results back here for future reference.

Best of luck.