This was funded through a Kickstarter, and a lot of backers are pretty bitter over the progress and direction of the project - just check out the forums.
I love the idea, but I'm very sad that this isn't open source.
I got excited about Pico-8 when I was reading, then I noticed its by the voxatron dev, THEN I notice it says if you already bought voxatron Pico-8 is free?!
I was hyped, now I'm hyped and happy. I was thinking about buying Pico-8, I wonder if this is a good business decision or not... I'll probably be raving on about it for a while now so the word of mouth might be worth $15.
Kinda makes me think 0x10c, developing games within a game. Someone should build hardware for this to run on :p
Zeb has said on Twitter that he's fine with people building new runtimes.
The limitations really make it easy to not worry and just make a dang game! For those of you worrying about cart size limits: if your game is too big for one cart, make it a two-parter :P
Also, apparently you can load data from another cart while your game is running so you could just chain a whole bunch of them together.
Two things I am really excited for are support on Pi-style hardware, and mobile support for the web player.
Pi is just a bit too slow to run the JS engine, it needs to be ported to native ARM for full speed.
 See http://i.imgur.com/1VOlxCt.png.
EDIT: reminds me a little bit of antirez' LOAD81 environment which is also, a bit of a retro programming experience:
I highly recommend this system to anyone. It's great and I've been having a tonne of fun with it. It's no Amiga 500, but boy it has that feel.
Built on Silicon-on-Sapphire process, it was radiation and EMSEC tolerant plus low-power. Used in Galileo space-craft. Highly reliable. It's still sold with a spec that you can fully understand and that documents every state:
So, not just a toy, Octo or CHIP-8 could be used to prototype applications that just run and run and run in the field. Heck, even a retro-gamer might appreciate a system that never freezes past game logic errors.
Eventually I would like to equip Octo with an optional 1802 emulation mode and the necessary mixed-mode assembler for producing 1802 machine code. Probably won't be available any time soon without strong demand, though.
Not sure how far you like to push yourself on low-level coding, reading on or doing it. I'll end with these links for your entertainment:
4-bit MCU's: the next challenge for 8-bit masters to strut their stuff. Interesting article esp how they're sold.
Example 4-bit CPU's for public
Note: Really wonder what best retro games would look like on 4-bits, esp after hardware acceleration tradeoffs. I always challenge the demoscene to show us. ;)
Motorola 1-bit processor: "Real men don't need hulking 4-8 bitters!" Haha
Note: Manual and source code are attached to comments on that page. Would be amazed at seeing people do anything useful in modern applications with these. They'd win by default on memory/power/area efficiency haha.
They have a very developer friendly environment (I spent many days programming there, they often hold Ludum Dare marathons) and Joseph is a first class indy developer.
Little excuse for arbitrary limitations even in retro scene. Exception is demoscene where it's kind of the point.
Here's an emulator: http://www.zx81stuff.org.uk/zx81/jtyone.html
32k is not a pita, its the point, this is a fantasy retro consol, giving it 32 MB would do what ? make it pointless probably
Its also a excellent opportunity to show off, for example, nobody would have thought you could make this on a C64 1984
Also note pico-8 limits the number of instructions executed per frame. So a faster CPU will not increase what you can do. The goal is to make sure all games run even on the least powered hardware.
At the same time, I feel the size limit is intended to have the same spirit as the audiovisual ones. Or, if one really wanted the PICO-8's features, but with more space, she could easily recreate the same functionality with another game framework pretty quickly. Perhaps it's almost like a tribute to stuff seen in the C64 demoscene.
As a programmer who's not good at compressing stuff, it would be annoying to have to spend time bashing code to fit an arbitrary limit.