Unity 5 bug? DontDestroyOnLoad with AudioSource failing on Windows standalone build

My game includes a UI that loads upon startup, sets itself with DontDestroyOnLoad on Awake and persists between level loads. The structure is as follows:

• UI (in scene root, no parent) - has multiple scripts attached
  • Canvas (with children)
  • Audio - has a single Component, AudioSource

In the Editor, the system works perfectly - the UI object, along with all its components and child objects, maintain their state. In a Windows build, however, after 3 or 4 level loads, the following message appears in the player log:

Unloading 3 Unused Serialized files (Serialized files now loaded: 0)
UnloadTime: 1.104330 ms

Unloading 214 unused Assets to reduce memory usage. Loaded Objects now: 1062.
Total: 0.683746 ms (FindLiveObjects: 0.046304 ms CreateObjectMapping: 0.033523 ms MarkObjects: 0.281600 ms DeleteObjects: 0.317847 ms)​

After this message is generted, the UI objects, its scripts, and the child Canvas all stay alive correctly, but the Audio object gets destroyed. This doesn't seem like intended engine behavior, any thoughts on the matter?

[EDIT]
I moved the AudioSource component to the UI object, and now it is being preserved. So something to do with the fact that the Audio game object is a standalone object with no scene references to it (it is being accessed by GetComponentInChildren) is causing it to be destroyed regardless of the DontDestroyOnLoad on its hierarchy. Bug?

 

Each object in the hierarchy has to be registered to not be destroyed. I don't think its a bug. I would have to say that its probably better to not have all children stay on a scene load unless explicitly told to not be destroyed.

 

That's not true - see DontDestroyOnLoad documentation:
"If the object is a component or game object then its entire transform hierarchy will not be destroyed either."

In any case, I tried it and it didn't help. If this behavior is by design I would expect it to occur in the editor, and after every level load - not only when the engine is doing cleanup.

 

Then it is a bug, not by design. Should be filed as a bug, I don't see it on the tracker.