Hi @johnwargo,
Thanks for posting your experiences and feedback, it’s very valuable!
I agree that the error messages and hints you got from the API in this case were probably confusing, and could have been more helpful. As an engineer building tools like this, it’s critical that we accept and internalize feedback, especially when it challenges our assumptions about how something should behave! So, tl;dr; thanks! I agree that we can make the errors more helpful. I plan to bring this up with the team, and talk about how we can improve on our end.
There was a question mentioned, “Why doesn’t the cloud API just tell you a variable over 12 characters would never work?”. I wanted to share some backstory on that in case it’s interesting. 
Your question is awesome, and the answer involves some assumptions I made, and limitations we had on the Core. The Spark Core had 20 KB of ram, about 4K of which was available to user apps. Registering variables and functions impacted that space, and they couldn’t be dynamically reserved like they are now (I hope?). So limiting the length to 12 bytes was a decision that happened in firmware for the Core, but wasn’t a constraint that needed to exist on the cloud.
I figured we wouldn’t have the same hardware limitations forever, and certainly people might make their own hardware, so the cloud didn’t worry about how long functions or variable names were, it would defer to the device itself to set those limitations. The device would be the source of truth. This is really convenient for someone building a giant distributed system, and it’s nice for being flexible, but it can be confusing if you don’t have that knowledge. I’ve also been caught at times by similar assumptions around our security model when I’m trying to call a function only to discover it’s on a device I don’t own, etc, etc.
Anyway, that’s all to say, thanks again for the awesome feedback, I love when people post stuff like this, and we’ll keep trying to make things better on our end.
Thanks!
David