Go/Go Tools?

It looks like you're leaning towards making the different uses of go optional, which is good. We should probably default to true for everything except go test, which should default to false (test suites can often be cumbersome and long-running).

gofmt still exists, but I believe the modern recommendation is to use go fmt. Can we do that here to be more future-proof?

Perhaps "This file contains formatting errors and should be run through go fmt" ?
Also, shouldn't this be checking the output or return value from the format command? Seems like it just unconditionally adds the comment now (maybe that's still part of the WIP?)

Since we have the output already in a variable, it's kind of silly to write it out to a file and load it back in. We can just do:

try:
    json_data = json.loads(cleaned_output)
except Exception as e:
    ...

The imports should be in alphabetical order. So import json should be placed before import logging.

Using the string's "split" method isn't portable (for example, windows doesn't use "/" as a path splitter). That said, there's both a portable and easier way to do this:

package = os.path.dirname(path)

It looks like we're running this for every single file, which means that if you have multiple changed files in a given package, we'll add the test failures multiple times.
Instead of overriding handle_file, can we instead override handle_files, and use the file list to build a list of changed packages? We can then run the tests once per package.

Let's pull the result of dest_file.lower() out into a variable so we don't have to call it twice in these checks.

Blank line between statements and the start of new blocks.

Same here.

This will scan the entirety of packages every iteration of files. If packages is a set, this will be faster, though then we lose the ordering. Perhaps that's okay, and we can sort the results when iterating it?
If so, we can safely .add() into a set without needing to check existence first.

This can fail, so we'll want to check for exceptions, just as we do further down.

It's generally better to use %-formatted strings to join in variables, as this is faster in Python.

We prefer %-formatted strings, rather than .format(), as it's technically faster and more consistent with the rest of our codebase.
This can also be combiend with the previous line:

formatted_output = '[%s]' % ','.join(gotest_output)

When spanning lines, we prefer the % on the line with the variables, as it gives more room for the strings and helps more clearly indicate that we're formatting variables in.

No blank line here.

Can you incorporate the package name in here, or something to help debug this if this comes up in production?

Same as above regarding %-formatted strings.

Let's use single quotes here, since the inner string doesn't use them. We prefer single quotes in Python strings wherever possible.

If we compile this regex before we do the outer loop, it'll speed this part up.

While common in Python, we shouldn't ever override _. That's because _ is commonly used as an alias to ugettext or ugettext_lazy, and this can have unintentional side-effects.
Also for items, we need to use six.iteritems() to get consistent behavior between Python 2 and 3.

Rather than putting this into a variable and pulling the indexes out, let's just unpack with:

filename, line_num = \
    os.path.basename(key['posn']).split(':', 2)


Could you also put a comment above this showing the general format of what we should expect here, so it's documented?

You can put the format argument on the same line, since it fits. No need for parens there either, since we're not building a tuple (only one arg, and also (message) is equivalent to message since there's no tuple indicator, like a trailing comma or a second value).

No blank line here.

Same comment as above regarding having identifying information in the message.

Things within here are getting pretty deeply nested. Maybe break out the test and vet implementations into their own methods?

This should be wrapped in a try/except.

Would it be possible to add a comment showing an example of what the JSON output from go vet looks like? That way people looking at the code can see how it maps to what it's parsing.

This is potentially running a lot of times, since it's deeply nested inside several loops.
At the top level, can we create a new dict that maps the patched file path back to f? That way we can just index into it instead of looping every time.

Ship It!