JobTempAlloc has allocations that are more than 4 frames old, why is this a problem?

Due to how jobs are prioritized I'm fine with certain jobs being pushed back for more than four frames. The important thing for me is that when I prioritize certain jobs they're performed asap and others are fine to be delayed. This goes hand in hand with the ability to say I need this job done this frame.

A bit of context, I'm working on next gen UMA (an open source character customization system) whenever a character is close to being visible I want to start spawning the character, currently we're building one per frame to keep a solid frame rate, with jobs we expect to be able to do more than one per frame. So the optimal scenario is of course that all characters are spawned before they could be seen. However if someone opens a door or something that changes priorities, so I want to be able to prioritize the nearest characters such potentially stalling a potential character for more than four frames. Honestly at the framerates I'm targeting I wouldn't mind a low priority job to be stalled twenty frames or more.

Version: Unity 2018.1.0b4

Edited: Version to b4

 

The "4 frames old" things came up before:
https://forum.unity.com/threads/job...tions-that-are-more-than-4-frames-old.513124/

 

I guess my scenario is different because I'm not using static anywhere and yet it's the same. It's the copy constructor of the NativeArray that doesn't store the "Persistent Allocation" flag. In uma we have several source assets that are stored in readonly lists. These are then passed to jobs and here it seems the system either flags them as temporary or worse copies them. Copying the entire mesh data before allowing the job to run would be a crime to performance.