I’ve received my 2 boards and shipping shows it took 2 months to get t me. 
They look good but until they get debugging working, I am putting them on the shelf. I just don’t like working with any development system without debugging. I hated Arduino for that too and tend to use them with Atmel Studio a 1-wire debugging.
Looks like TinyCLR is starting to get my attention instead. 
Still waiting on the one I ordered from the site. I know that doesn’t take 2 months to reach me.
Yea, I concur. No debugger is a non starter; not in this day and age.
Got this from Bryan at Wilderness Labs when I asked about a timeline for the debugger. Like all the other timelines, I suspect this will be quite some time yet.
You can still get debug info via Console.WriteLine. We've used that successfully during all of our development.
We don't have a timeline for debugging support yet. It'll be in the next major beta release, and we've got a good portion of it done, but we're not sure how much work the next part of it is.
No better than Arduino as far as I am concerned. Yes, you can work without a debugger but look how long they have taken to get Meadow working, as it is. 
I haven’t even powered the thing up yet, because without debugging it’s just a frustrating toy (not fit for real apps), and I have enough less-frustrating toys that I’ve been meaning to get to.
Even with a fully functional Meadow, you’re trading one interpreter family (netmf/tinyclr/nano) for another (mono) and gaining syntactic sugar, but losing a lot of performance, community support, and ready-for-use functionality, while simultaneously driving up BOM cost.
The economic benefit of .net interpreters is the reduction in development cost balanced against small runs of increased BOM cost. Meadow devices add a bunch of BOM cost in exchange for very marginal (promised) feature and productivity gains, so beyond hobby use, the economics of fielding these devices seems out of whack. Nevermind that they aren’t ready for real dev work yet.
Can I use this in my next presentation? 
I would argue that with nano running on esp32s that you can actually reduce the bom cost.
Esp32 $4 STM32 running NETMF/Tinyclr $2
And by the time you add wifi and Bluetooth? Way more dollars. Now you could go c++ and use a arduino for $0.50
Enjoy yourself 
Even if you had it running on an ESP32, you would still need extra BOM parts for the USB port unless you just connected to the serial port with an external USB to SERIAL?
I love the ESP32 and busy trying to get my head around the IDF as I now have JTAG working with Visual Studio and Visual GDB. I’d love to have C# on this thing.
Oh Dave there is c# on the esp32! That’s nanoFramework.
And that is with the debugging power of VS2017 or VS2019, take your pick.
When I talk about all interpreters increasing BOM cost, I mean that you need extra bytes of memory and extra cycles of cpu to run the interpreter, so for any given chip set you can do more on the same hardware with native code. The problem being, of course, that you spend a heck of a lot more on development, so if you aren’t making a ton of pieces, netmf-family stuff is cheaper. I think you come to the same conclusion a couple posts below re: C++ and arduino-class MCUs.
Big +1 on VisualGDB. That and a cheap JTAG or SWD dongle and you’re off to the races.
I though you meant BOM as in bill of materials 
I concur, If you’re intending to make millions of them and execution speed matters: C++
If running on battery and the device spends 3 seconds to do a task as opposed to 0.5 seconds, before going back into standby, then the code execution speed will drastically reduce the battery life. This could mean the difference between being able to run on solar or needing constant battery replacement; a major concern of IoT devices.
Maybe you could check out this little monster from OrgPal running nanoFramework (C# interpreter) and running on solar. It can even power on itself. And has a lot of goodies.