Controlsdude, not sure if those last comments are about what I wrote or not, but if so then I will try to respond.
"so you feed a box on how when the main sorter is at full speed?"
The prior conveyor would have a PEC that is used to stop the box if the sorting conveyor is not running (or about to stop). If this conveyor is long it would need a brake, shorter conveyors can usually stop OK quickly, this conveyor would be restarted a short time after the sorter conveyor had started. These conveyors should be speed matched, not necessarily VFD's, but the important thing is the box passes between conveyors without the drag that can be caused by different speeds.
"fifos lose track of most boxes"
I understand where you are coming from, if you use a FIFO where you say the first in will be the next one detected then it would invite trouble, a box falls off, a box is added or two or more boxes close up would screw everything up. But that is not what I suggested, a FIFO can be used very successfully if you include the expected data, that way the item can be cleansed or identified as unknown.
"not using vfds for ramp up and down is just inviting more bad tracking."
Which is why I stated that without a VFD the conveyor system should be able to empty out, i.e. enough space downstream to be able to stop the preceding conveyor and empty the sorting conveyor (budget was looking a possible problem for the OP so this would save the need for a VFD) and boxes should not be restarted until the sorting conveyor has restarted. Having said that a 50 foot conveyor may not be feasible for this.
"all this last info is just asking for more bad tracking."
The last info is coming from an engineer who's been tracking objects for more than 20 years including secure airport systems.
"there are only a few solid ways to track on a sorter, I think i pointed out the best ways and the pitfalls. I think trying to fill the holes on a fifo track will take forever."
There are many ways I agree and I have seen some that made my heart stop. I'm not sure I understand the holes in FIFO.
My original post was not so much endorsing a FIFO, just countering the argument that a FIFO is a disaster, this depends on how you use the FIFO.
To track you would usually create an ID for an object as it enters the tracking zone, this ID would normally represent a position in an ARRAY, this ARRAY is where you store info on the object. On creating the ID, the ARRAY position for that ID is cleared.
After reading the barcode a destination is determined, either this data is sent elsewhere for a destination or the PLC would hold a store of expected barcodes and predetermined destinations.
The ARRAY may contain data such as the read barcode, the destination, read status, push status, etc.
Some tracking methods:
Have a table long enough to contain a position for every pulse position, move the ID into the bottom position and then block move the table by one every pulse. When the object reaches a decision point check the destination.
Have a table long enough to contain a position for every pulse position, have a pointer to the start position and each decision point, move the pointers each pulse and the data remains static. When decision point pointer sees an ID check the destination.
Put the ID into a FIFO and include a count value when the object is placed in FIFO in the ARRAY, the count increments per encoder pulse and the object removed from the FIFO when the count reaches a value of inserted + distance.
In all cases, the tracking will never ever be 100% accurate, so a tolerance has to be created, if an object is expected on pulse 60, then start looking for it at pulse 55, if not seen at 65 then dump the ID.
If an object is detected when one is not expected, then give it an ID and a destination for unknowns (the last destination normally).
At the end of the day there are many ways to skin a cat, there are many correct answers and quite a few wrong ones.
None of us who attempt to pass on knowledge are in full knowledge of what a requester's requirements are nor do we know their restraints.