Unfortunately no to both. The part is still incorrect. From the gerber drill file obtained by exporting the pcb to gerber file->export->for production->extended gerber, in my case Untitled Sketch_drill.txt:
; NON-PLATED HOLES START AT T1
; THROUGH (PLATED) HOLES START AT T100
M48
INCH
T100C0.037000
T101C0.040000
%
T100
X014222Y008222
X014222Y010222
X014222Y007222
X014222Y011222
X014222Y012222
X014222Y009222
X014222Y013222
T101
X014222Y014222
T00
M30
we see a number of problems: the hole size is .037 (not .038) for 6 of the holes, one hole is .040 making pcb incorrect. Switching to svg.pcb.MPU6050_GY521_782354e339f672575bb20992ece4ab1b_9_pcb.svg (the pcb svg in your part) there are also a number of problems: The first group g58 has a translate. In pcb translates get tricky in that the values are supposed to be inherited but that doesn’t appear to always happen. The safe way is to eliminate all the translates in pcb. The next problem is that pads don’t have my corrected parameters (I’d guess because of the translates being used to change the coordinate space to approximate the correct values because they are almost right). I don’t see why one pad is .040 instead of 0.037, but my guess again will be translate somehow. As I said the r wants to be 29 not 28.5 and stroke-width wants to be 20 (with no translates) which should produce the correct size holes of 0.38. So in Inkscape xml editor I selected the top group (g58) and then hit shift-cntrl-g to ungroup until there were no groups left. The left me with pin0 with a stroke-width of 17.x and the rest at 20.x and the radiuses at 28.5. Using xml editor to change the radius to 29 and the stroke-width to 20 and then regrouping silkscreen (including the text) and copper1/copper0 should produce the correct pcb svg. The different stroke width on pin0 will be why the one pin was a different size (and indeed appears to be caused by the translates).
I’ll look this one over in a bit. Unfortunately like many things in Fritzing, replacing an existing part is complex (there are special undocumented anywhere I am aware of commands in the fzp file for doing this). What usually happens is that el-j (the parts maintainer) manually does this because he knows how and at least I don’t 
which is why there can be a delay in getting a part added and sometimes a part will be rejected as it can’t be converted
edit: Again a number of problems: Schematic and pcb aren’t scaled to 10…41667, schematic pins aren’t aligned on .1 boundaries (they are a little high, possibly an artifact of the original not having height/width specifed in inches but rather px and being misscaled). Pcb doesn’t have an outline of the size of the complete board in silkscreen and the connector holes are 0.030in and should probably 0.038 for .1in header pins which is typically what these boards come with.
Peter