Currently, the multifilesink will check its GstCaps for a "streamheader" value.  If this value exists, it will then generate a header for each file.  

However, there are several instances where being able to treat each file generated by the multifilesink as a continuation of the previous file.

In no particular order, and this is not an exhaustive list:

1 - splitfilesrc playback.  This element treats a set of files as one large contiguous file.  Unfortunately, headers mess up a variety of demuxers.
2 - moving files between file systems.  For example, FAT32, common on SDCards, is limited to 4GB files.  Being able to binary concatenate files together when transferred to a file system without such a limit would be very useful.

To solve this, I propose adding a "write-stream-headers" property, whose default is "true" (to preserve current behavior), but when set to "false" will not write "streamheader" information from GstCaps into the resulting files.