It generalizes the choice of 0 or 1 to an arbitrary starting index. So when you create an array you specify not just where it ends but also where it begins. This lets you do neat things (consider a filter kernel with range [-s,+s]^n instead of [1,2s]^n) and the extra complexity it adds can be hidden when not needed using for-statements or higher order functions.

Nobody uses it because the implementation is not very efficient and Haskellers have a chip on their shoulder about performance. It subtracts the origin and computes strides on every index, but you could easily avoid this by storing the subtracted base pointer and strides with the array. Of course when you go to implement it you'll see light on 0-based indexing :)

The only way I could think to manage it would be a pragma which switches 0-based on for a given file. But this is doubtlessly not trivial.

Or there is the less elegant option of introducing a new operator for 0-based arrays. But this is liable to cause confusion I think.

However, as I've used it more and more, 1-based indexing has really grown on me. I feel like I make far fewer off-by-one errors and actually hardly ever have to think about them. This has led me to conclude that 1-based indexing is probably easier for humans while 0-based indexing is clearly easier for computers.