I'm not sure this should be documented in json.load/loads, and I'm not sure people will look there once they get this exception.
The error is raised because the wrong codec is used (either by open() before passing the file object to json.load or by json.loads), so it's a user error rather than a problem with the json module. The error turns out to be particularly misleading because the decoding is successful even though it produces a wrong result, and the problem becomes apparent only once it reaches json.
ISTM that the documentation is already clear enough that json doesn't auto-detect encodings and uses UTF-8 by default, and that different encodings should be specified explicitly.
I think that a better and backward-compatible solution would be to detect the UTF-8 BOM and provide a better error message hinting at utf-8-sig.

I like the new error message as a low-risk immediate improvement that nudges people in the direction of utf8-sig. It also leaves the door open to silently ignoring the BoM in the future without immediately committing to that approach.

Discussing this with Ezio on IRC, we decided that it probably makes more sense to do this check outside the scanner as preliminary validation of the input passed in via the public API. That will minimise the overhead and also avoids any potential side effects if "idx==0" is ever true in cases we're not currently testing.
The tests from the current patches should be OK, though.
Ezio also found that, for Py3k, adding an explicit check for non-str input and throwing an appropriate error would also be an improvement over the status quo:
>>> import json
>>> json.loads(b'')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/ncoghlan/devel/py3k/Lib/json/__init__.py", line 316, in loads
return _default_decoder.decode(s)
File "/home/ncoghlan/devel/py3k/Lib/json/decoder.py", line 344, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
TypeError: can't use a string pattern on a bytes-like object

I opened a new issue about improving the error message: #19307.
After further discussion on IRC, we think that both #19307 and this issue should only be applied on 3.4 (the attached patch produces an even more misleading error that would require backporting #19307).