How bad is it if I were to publish records for a non-existing lexicon just so I could experiment? What do you all do when experimenting?
Main question I have is, how necessary is it to purchase a domain so that I can publish these experimental records.
I don’t know if it’s bad per se, but it is obviously risky, since someone else can register the domain and publish their own lexicons that conflict with yours. Consuming applications and clients may then break, mishandle, or ignore your records.
Free subdomains on someone else’s pay-level domain are an option. Or, if cost is a concern, here are resources for free and cheap pay-level domains, eg $1/yr .xyz:
(Another hypothetical option could have been NSIDs on reserved TLDs, eg .example, but ATProto doesn’t allow those in NSIDs.)
Maybe it would be a worthy cause to provide a namespace that people could use specifically for this.
For example if we had a domain like lxm.dev, we could host an app for claiming sub-domains based on your ATProto handle, such as dev.lxm.social.bsky.zicklag.test-app.post maybe?
That’s super long and there’s an issue maybe if you change your ATProto handle. 
It could be based on your DID instead: dev.lxm.ulg2bzgrgs7ddjjlmhtegk3v.test-app.post.
Or it could just be first-come-first-served: dev.lcm.test-app.post. But that’s annoying because it opens up more abuse vectors.
DID-based would probably be the simplest and safest. Assuming DIDs are valid NSID segments. 
You’d also have to support did:web.
I bought nsid.at and i’m interested in setting up a basic dev flow around it.
If you as bmann.ca published lexicon schemas to your atproto repo like at.nsid.bmann.project.someRecord, the auto-NSID service would detect that on the firehose. It would check if another account was already using the at.nsid.bmann.* namespace, and then check if “bmann” was part of your current active handle. If it was, and some other conditions were met (rate-limits, that your account was at least a week old, that there wasn’t a wave of bulk-registration happening, some keyword blocks, etc) it would grant your DID control of that sub-namespace, and would configure DNS records for lexicon resolution. Possibly recursively, so any sub-sub-namespaces would all resolve.
The registration database (sub-namespace to DID) could be published publicly.
The goal is that for a lot of devs you could just start publishing lexicons and it would Just Work in a casual way. I think you always need to add anti-abuse checks and have policies and break-glass tooling anyways.
Cool!
And yeah, I think if you did root-or-subdomain user string and match on that it could be one way. Or, just squoosh them – so bmannca and bnewboldnet and alicebskysocial – which gets you uniqueness.
Re: abuse - owning the domain name gives the ultimate yoink for this of course.
Apparently this is now a nerdsnipe category not a FAQ channel 
To reply to the OP: sort of depends on what “publish” and “experiment” mean.
If you are just developing and experimenting locally on your own account, own software, etc, then you can just write lexicons locally on disk. You could put them in software version control, but don’t need to publish the schemas as atproto records. I don’t see much value or benefit in publishing lexicon schemas as atproto records unless they can be resolved in some way or another.
That is also the case when developing with existing published Lexicons, eg adding new (optional) fields to existing schemas that you control.
What is blurry is when a project moves from “alpha” or “beta” status to “generally available” or “out in the wild”. Sometimes that is a project/developer choice (you make an announcement), but sometimes the network can yank that out of your hands (eg, you were experimenting but suddenly other devs and users are using your lexicons without asking you). I think basically once there are a hard-to-coordinate number of accounts using lexicons, or multiple independent apps/projects building on lexicons, it is best for those schemas to get published and be resolvable.
Another option is to use the .internal TLD in the NSID to indicate that the lexicon is not intended to be resolvable or interoperable. These NSIDs will never resolve on the public network.
Mostly an echo of what Brian said, maybe a little simpler:
You don’t need to publish your lexicons ever. As an example, Popfeed’s lexicons remain only available via their git repo. They have yet to be published to the network.
As far as the issue of losing the domain during experimentation, it’s a trivial concern. Other applications can write to any collection if they have broad enough scopes, so you must program defensively regardless of whether your lexicons are published or not.
The best bet for development is to keep your lexicons local, use a .internal NSID, and only write to a small set of repos you have control over. That way it’s easy to migrate your lexicons and wipe old records before you ever launch anything.
One other note: the core value prop of lexicon publishing and resolution is for lexicons intended for interop. If you don’t intend for other apps to take advantage of the same data, you never have to worry about it. However if you’re writing permission sets then resolution becomes a hard requirement.
Another tip for people who want to prevent others from using their lexicon. Just make it completely awful:
internal.d118034469bed3158637d62e0d49f951963c524a1f5a7a39fdcaa254a0ad3ee.doc
Hmm, are .internal NSIDs even usable? Namespaced Identifiers (NSIDs) - AT Protocol says the domain part of an NSID has to be a valid handle, and Handle - AT Protocol says .internal isn’t allowed.
Follow the rules until you need to break them. 
Reasonable question! I think the NSID syntax rules should align with handle syntax rules. And the handle non-syntax restrictions should also be non-syntax restrictions for NSIDs as well (eg, as part of the resolution process).
I created a specs tracking issue here: specs: clarify NSID syntax reference to handle syntax · Issue #763 · bluesky-social/atproto-website · GitHub
…and until you need interop anywhere. 
I recommend putting your stub lexicons on a lexicon.garden namespace. It will provision you a unique subdomain. Great or experimentation.