Shane is correct that this is expected behavior. The use of --header with starch is intended to help make the compression format "non-lossy", so that "unstarch" will be able to recover that data.
However, starch/unstarch do not place any requirements on how other tools will process headers from extracted data, and a consequence of generating sorted input for use with other BEDOPS tools will generally strip this header data. Also, the starchcat tool will not concatenate starch files with header data.
One exception is the use of --header with data acquired from other genomic formats, using the convert2bed tool (gff2bed, etc.). In this case, metadata elements at the start of non-BED data are given a pseudo-chromosome name and genomic interval when transformed, which allows them to be sorted with sort-bed as if they were normal BED elements. This allows them to be preserved in downstream BEDOPS operations.
So one option is to mimic this approach, such that given the example input:
#some_metadata
#some_more_metadata
chrN X Y
...one might instead make a fake BED element with a pseudo-chromosome name of "_header" or similar, e.g.:
_header 0 1 some_metadata
_header 1 2 some_more_metadata
chrN X Y
Unless there are chunks of metadata strewn throughout the BED file, the final result of any BED operations on this kind of data is easy to revert to the original header format.
