This is looking good to me, but please wait for dae to give it a look too.

Hi, sorry for asking here, but does your implementation consider all nested decks when choosing the random deck?

If that's the case, then it might make the randomness biased towards decks with many many subdecks. It would also break the order criterion. For example if we have:

DECK         
┣━━SUBDECK 1
┃  ┣━━SUBDECK 1.1
┃  ┗━━SUBDECK 1.2
┗━━SUBDECK 2      

with cards in SUBDECK 1.2 having a larger position than those in SUBDECK 1.1, then we wouldn't want SUBDECK 1.2 to be chosen if SUBDECK 1.1 has new cards available.

What I had in mind and probably others too, was that it would simply pick a random direct subdeck of the deck we click on to study and "flattening" all the nested subdecks (treat all the cards in the subdecks of a direct subdeck as if they were in the direct subdeck).

[I originally didn't consider the deck itself.]

With the example above, when clicking on DECK, it should pick one of DECK, SUBDECK 1 and SUBDECK 2. If it picked SUBDECK 1, it should then pick the new card with the lowest position in SUBDECK 1 and both its subdecks (which is the same as the first new card you'd see if you open SUBDECK 1 in the browser with the cards sorted by due date ascending).

Edit: (unrelated to my points above) a possible improvement is to weight the subdecks by the number of new cards available to study, so that we don't end up with many cards from a subdeck which has a larger new card limit.

This PR picks a random descendant deck rather than a random child deck. I think you may be right, for unbalanced trees it could be better to distribute among the children (and self) rather than all the descendants (and self).