There is arguably no good definition for toInteger, though it depends on what you expect it to do. It cannot be a (non-trivial) ring homomorphism, for instance.

For quotRem, you ought to at least test the Euclidean division property: that the norm of r is less than the norm of the divisor.

The tests for the Integral instance don't really validate that it's a good definition. Probably because there arguably is no good definition.

The following passes:

instance Integral Gaussian where
  toInteger = const 1
  quotRem z w = (1,z-w)

The expected behaviour of take and drop should be documented. Yes, it agrees with the Prelude, but zipWith does not, and and they are not what I, at least, would expect. Either that, or let us see the test cases so we have a chance of figuring out what the type errors mean.

The definition of fold in the description has the arguments in the wrong order.

Failing test cases should show the failing string.

It's lazier; it works when is is infinite. I suspect (though I don't exactly recall) that's why I wrote it that way in the first place. Of course, the requirement to return the lexicographically least solution prevents doing anything useful with infinite lists, so it got transformed into this solution.

If you're bothered by the possibility of creating nested loops, you could manually fuse it:

indices is = unfoldr go (0, is)
  where go (_, []) = Nothing
        go (a, _:bs) = Just (a, (a+1,bs))

But I don't think that is necessary.

The real problem here is the use of (!!), turning what should be a quadratic algorithm cubic.

The empty list is a sublist of any list. So zero, as the sum of the empty list, is a candidate solution for any list. If all of the entries in the list are negative, then zero would be the largest sublist sum, if empty sublists are allowed. This is not currently the behavior expected by test cases. You should probably at least specify what the expected behavior is (i.e. maximum over nonempty sublists) or, perhaps more naturally, change the tests so that the empty sublist is considered a candidate.

The description should specify that this expects a maximum over nonempty subsequences. My natural assumption was to treat empty subsequences as having a sum of 0 (which makes for a particularly nice solution). With this specified, you also have to require that the input list be nonempty, so you should also specify whether solutions have to care about that case or not.

Nah, these are artisanally hand-emplaced (.)s.

There should be test cases to verify that Nothings are being correctly handled in the interpreter, i.e. something like 1 + 1/0 should be Nothing and not produce an error.