Sorry, the 2nd example is wrong, here is the correct one.

<?php
$fp = fopen('a', 'a+');
$s=ftell($fp);
fseek($fp, $s+100, SEEK_SET);
fseek($fp, $s, SEEK_SET);
fwrite($fp, str_repeat('1', 100));
fclose($fp);
?>

What happens here is that you open a file in append mode
and set the filepointer in the end of the file.
Now when you truncate it to 100 bytes, the filepointer
is still in the end. And when you add the 100 bytes, they're
added in the end. 

You should open the file in 'w' mode.

AFAIK, this is the correct behaviour.

No, this is not correct behaviour.  Assuming file 'a' does not exist or is of 0 length when we start, then $s should return 0 on the ftell().  ftruncate() should create a 100 byte file containing nulls *but* by definition it should not move the file pointer.  The file pointer is still at position 0.  So when the fwrite() happens the 100 nulls should be overwritten by the 100 1's.

Try this test program in C:

#include <stdio.h>

int main() {
    FILE *fp;    
    int s;

    fp = fopen("a","a+");
    s = ftell(fp);
    ftruncate(fp, s+10);
    fwrite("1111111111",1,10,fp);
    fclose(fp);
}

(didn't feel like typing out 100 1's.)

Looking through Wez's streams code I don't see any obvious bug there.

Actually, Jani is right, it should work this way, quoth the C manual:

If the file previously was  larger  than  this  size,  the extra  data  is lost.  If the file previously was shorter, it is extended, and the extended part reads as zero bytes.

Odd that your example doesn't show it :)