Some notes of my thoughts on this matter:

• I think having a single node with different datatype modes is totally fine
• I do think we should also include the different random distributions in this node that were worked out in this patch D10459 (exactly in its latest state)
• For a boolean output it would be nice to have a probability ratio parameter (p_True = 0.5)
• It was mentioned somewhere that this node (randomization nodes in general) could have a specific node seed. I think that is a great idea, I brought up the issue of changing seeds between nodes in the past. This does result logically in 3 Seed inputs though:
  • node seed (randomly changed on node adding/ maybe duplication)
  • index (not exposed slider, if nothing is plugged in it used the Index field)
  • seed (seed to be changed on top of the node seed, equivalent to what this node had previously. it allows to expose a single seed to the modifier interface for example)

For the index input:

• I would like to retain the functionality that generated points from the point distribute node to generate stable random numbers by default. So maybe the index could look for the generated hashed id first and then fallback to the Index field

@Johnny Matthews (guitargeek) I abandoned D10459, please use as you wish, the additional code was adapted from python functions.

In D12603#329400, @Simon Thommes (simonthommes) wrote:

• It was mentioned somewhere that this node (randomization nodes in general) could have a specific node seed. I think that is a great idea, I brought up the issue of changing seeds between nodes in the past. This does result logically in 3 Seed inputs though:
  • node seed (randomly changed on node adding/ maybe duplication)
  • index (not exposed slider, if nothing is plugged in it used the Index field)
  • seed (seed to be changed on top of the node seed, equivalent to what this node had previously. it allows to expose a single seed to the modifier interface for example)

For the index input:

• I would like to retain the functionality that generated points from the point distribute node to generate stable random numbers by default. So maybe the index could look for the generated hashed id first and then fallback to the Index field

I mentioned an idea about seed offset which seems to be similar to a combination of the second and third option you typed here. My idea was that the seed slider would actually act as an offset value for the Index field under the hood, and this behavior would be able to be disabled by a checkbox or something if you want a constant random number. What do you people think about this idea?

In real life practise random number over different index is used in way more cases than a constant random number so I just believe the default behavior should do the index thing on its own. But we still need a value for the modifier so I came up with the offset idea.

Not a full review, didn't test it yet. Just got a few small notes already.