11231
11[12.23,31 and 11] <= from first

11231 for 3
112[123,231, 311,111]

But it still is independent of the length. That solution crashes only for n > length + 1.

Thanks, I've added an upper bound for n, it should be between 2 and 8 (inclusive).

It looks like there's no upper bound for n dependent on the sequence length. In this case solutions like this can crash with out-out-range item access at large ns. Either tests with large ns or the upper bound for n should be added. (There are no such tests at least in Rust.)

Looks great to me.

Haskell translation

Please note I have updated the description: use double quotes for strings because Haskell reserves single quotes for single characters, moved the section explaining de Bruijn sequences up top, and minor updates to spelling, grammar and markup. If you disagree with any change, it can be changed again.

That is true, that upper bound is probably too broad 😅
I have amended the description as suggested and added the performance tag, many thanks.

I don't think anyone will figure out that last big-O. I have seen worse, but it's quite ridiculous. :P

I actually think "O(n), where n is length of output" would be the most understandable way of saying you have to be quite fast. And with tests ( or a test, at least ) of size 8^7, about 2 million, I can't imagine anything slower than that will work.

Thanks for the explanation and tips.
RE: your last point, so would this be appropriate:
Ω(k^n) and O(k!^(k^(n-1))/(k^n))
As we know at worst, they will generate every single de Bruijn sequence and then sort them?
I'll do some more testing anyway and see what I can workout.

Yes, thanks for catching that! I have changed it now.