If there could always be some way to count how many PG problems have been loaded on a page so far, that could be leveraged to get unique div ids. But that would mean always accounting for whatever is rendering the multiple problems (Library Browser, Set Details page, PreTeXt, etc, ....) and I think it's too much to work out.
Without having actually tried this I don't think it would be that hard to supply a unique id.
My initial idea was to put a counter in WeBWorK.pm (or even Apache::WeBWorK.pm) that is initialized when a new child process is created.
That would create an id unique to each child process. However it's possible that a problem won't always be processed by the same child -- so that approach is probably too risky.
Tying the counter to the database might work however. Simply have a table that records each instance of a geogebra app being created for a course and use the index of the row to make it unique.
That might be a little more work initially but it is more straightforward than trying to use time() to create unique ids. I've grown wary of using one thing (time()) to accomplish an unrelated task (unique IDs) if the goal is long term stability even though it is a very tempting fix for a quick proof-of-concept.
On further reflection I think this unique id problem might already have been solved, or at least a great deal of progress made toward solving it, in code that already resides in the WW repos.
If you grep through the code base for "uniq" you'll find a lot of other places
where a unique ID is being determined. In particular for the definitions of alias() in PGalias.pm and also PGresource.pm (and also in Chromatic.pm which does use time() ) UUID::Tiny is the CPAN module which we have already included in WW. You might be able to extend alias() directly to handle geogebra applets as it already handles images, html files and so forth.
See what you think.
By the way the random() function in WeBWorK does not use rand or srand to calculate it's pseudorandom string. It uses the simplest algorithm we could find in our number theory book for generating a pseudorandom string. That means that (as long as you use the same seed for the problem) random() is machine independent and you can transfer problems from one machine to another. We originally used time() and rand() to generate random numbers but that caused issues later with debugging on different machines (my Mac and Arnie's PC :-) )
Another option: https://metacpan.org/pod/Data::Uniqid which might have features that UUID::Tiny does not have. I'm sure that there are more cpan modules addressing this issue.