What also would be good is maybe a <r,l,u> scrambler that then solves the centres and DF/DB. that might potentially give a better scrambler for K4 ELL. just a thought.

That is the basic idea I had, but <r,l,U> is probably a little too much to compute for just generating a scramble. The search tree would get a value of 6 (9 initially) in width and we had to track 16 pieces.

I think MaeLSTRoM meant generating a random sequence of perhaps 25 or 30 <r,l,U> moves (similar to vcuber13's idea), not writing an <r,l,U> solver. Care would be needed so that solving the edge D Layer edges doesn't affect the probability distribution of the 8 LL edge pieces. (And, of course, an AUF would be needed to solve the corners, assuming you want them solved. If you want corners scrambled, then an extra move sequence for scrambling the corners would be needed.)

Keep in mind whether or not you want a scrambler that only "preserves" the centers on the 4x4x4 or works for all big cube sizes too. If so, then the scrambles will need to be longer and many optimal <U, r> algorithms that work on the 4x4x4 won't be able to work on other big cube sizes.

We've not been talking about any cubes other than 4x4x4 in this thread. And I've been assuming that centers on a given face are to be considered indistinguishable.

If anyone really wants a scrambler that has any chance of using fewer moves than a human solution, you must allow more types of moves than just <U, r>.

<U,r> seems to generate solutions of around 25 moves. I think that this would be adequate for what David asked for, even if the sequences might be longer in some cases than what a person would need to solve them.

What counts as an ELL scramble? Surely we all can agree that if 2, 3, or 4 (and probably 5) wings unsolved is not considered a scramble. So, the maker of this software should know if indeed 6 or more wings messed up is a scramble or not. That definitely would lessen the number of algs to be found.

I've been assuming the scrambler would generate any of the 40320 cases with equal probability - well, except probably rejecting the solved case. If additional easy cases are to be rejected, it is easy to do that when using a random state generator. With a generic <U,r> solver, you would not need to find any algs up front (assuming it can generate them fast enough). You only need to find algs up front if you are using an n-phase solver approach like what qqwref suggested.