Is there a limit of number of LPD queue names that can be defined in the LPD Input object?
There are no hard-coded limits, but don’t you dare go and create 408378558 distinct queues. 
On my NFR, I added a process with 11,725 queue names. It does take a very long time to restart the configuration. In the pplpd directory it creates all of the subfolders.
Is there a practical limit understanding that there are other considerations?
Noticed that jobinfo 6 with the queue name is now available which is great!
The label is maroon so there is a contextual menu, but trying to understand how the 3 items could be used.
If there was a repository list of queue names for example with all the 11,725 queue names, would that work making it easier to manage the queue names?
Maybe something even cooler?
The contextual menu items Get … Value allow you to retrieve a text value from the corresponding location at design time, but it will not be able to resolve those at run time.
As for a practical limit… Well I guess you hit one here with almost 12k queue names, which makes management and load times a bit of a pain. I would suggest that you go ahead trying to streamline and trim it down, as you suggested in another topic.
We are always open to suggestions to improve usability, although I think this here is kind of a corner case. From the top of my head, would an option to designate one LPD input task as a catch-all be useful? By that I mean a task that would receive all incoming jobs for which no specific queue exist, with the provision that the queue name would be available in the %6 job info.
I think that we will divide the LPD Queues into groups, Then have each group be handled by separate processes. We will need to test to see what the feasible limits are. Perhaps multiple PlanetPress servers and multiple print servers (10+) that PlanetPress delivers print jobs to.