OK, proof positive that even when sleep deprived I can still think :) 

[MethodImpl(MethodImplOptions.Synchronized)] really is the same as using lock(this) on the whole method.  I have a little test case below and I annotated the assembly...  note that you can't tell anything from the IL because the IL doesn't include the locking semantics explicity, they are added by the JIT.  So in summary Kit was definately correct and the PAG wording is ambiguous.

using System;
using System.Runtime.CompilerServices;

class Test
{
 static void Main(String[] args)
 {
  Test t = new Test();
  t.Go();
 }

 [MethodImpl(MethodImplOptions.Synchronized)]
 public virtual int Go()
 {
  return 1;
 }
}

000000      push    ESI  // preserve ESI
000001      mov     ESI, ECX  // “this” comes in ECX, save in ESI
000003      mov     ECX, ESI // dumbness :)
000005      call    MONITOR_ENTER // lock ECX (“this”)
00000A      mov     EAX, 1 // compute exciting return code
00000F      push    EAX // save exciting return code
000010      mov     ECX, ESI // restore ECX from ESI, “this” is back
000012      call    MONITOR_EXIT // unlock “this” 
000017      pop     EAX // re-establish return code
000018      pop     ESI // restore the saved ESI
000019      ret  // look ma, all done