Run ttyrec. Inside that, run screen. Inside screen, run vim, and open ttyrec.c.
Search for efopen.

If you play back the ttyrecord from that (I've attached one),
you will see a mess:

 if (optind < argc) {
 input = efopen(argv[optind], "r");
    } else {
 input = input_from_stdin();
    }

Apparently what displays as tabs when recording this is stored and
redisplayed as a single space. Note that this happens even if ttyplay is
run in screen -- which should cause it to play back identically.

Looking at the ttyrecord contents, I see this:

    } ^[[33melse^[[39m {^[[5D
 input = input_from_stdin();^M

The escape seqences are all for colorization; there is nothing to
move the second line over a tab. How does it display as one in screen
when being recorded, then? I don't know.

If instead you run screen, run ttyrec inside screen, and do the same thing
with vim, that plays back with tabs appearing correctly. Looking at the
ttyrecord recorded this way, I can see vim is emulating tabs by using
absolute cursor positioning (to 8, 13):

    } ^[[33melse^[[m {^[[13;8H input = input_from_stdin();^M

I also tried not using screen, but setting TERM=screen and using vim
as before. When this is done, ttyrec again managed to record the vim's
use of cursor positioning, and it plays back ok.

I have to conclude that, somehow, screen is moving the cursor in a way
that is not recorded by ttyrec. The only way I can imagine it could do
this is if it's somehow finding and opening the master tty, and sending
cursor movement commands directly to it. Bypassing ttyrec's recorded slave
tty.

Workaround: Use tmux instead of screen when using ttyrec. Meh.