I have not seen this before. Note that NoData is handled at two different levels. Item and Service.
At the item level each raster inherits NoData from the source raster and you can add a Mask function to change or add NoData. This will define what is NoData prior to images being mosaicked together. The Mosaic Dataset itself also has a NoData Property which defines what pixel values should be assumed to be NoData for the resulting image. Additionally there is a property of the Mosaic dataset called "Footprints May Contain NoData". You many want to check this property.
When you create a derived Mosaic dataset the NoData from the Items are copied across, but not from the service level. Are you sure in your source Mosaic datasets that the NoData was defined at the Item level?
I typically recommend not to use NoData values, but instead us the footprints of the images to clip out areas that are NoData. Clipping the imagery by footprint is more efficient then using NoData especially in cases where there are lots of overlapping images. The system can very quickly determine what pixels need to be rendered or not from each contributing image without needing to actually read the pixels. Consider doing a build footprint to change the footprint to only the image extent. Alternatively you may have a geometry (eg original sheet cut) that defines the extent of the imagery and you can import this as footprints. If there is overlap between the images consider shrinking the footprints if the edges are a bit messy.
There are cases where the NoData areas are too irregular to use the clipping method, so you may be forced to use NoData.
