(I'm not a uap-core maintainer, so can't approve this PR). Right now the way this works for uap-go is that we have uap-core as a git submodule and manually run our./build.sh script which updates the submodule & copies the yaml into a .go file in this repo. Is the idea to simplify that somehow?

Yeah. No submodule needed. No build.sh, no source file with inline yaml data. All manual tasks/scripts can be removed in favor of a go native solution.

Sounds nice. Would that mean users of uap-go could use new uap-core regexes without a uap-go update? That would certainly be nice. (though we've also had the occasional case of newer regexes revealing bugs in uap-go so it's not without risks)

Sounds nice. Would that mean users of uap-go could use new uap-core regexes without a uap-go update?

Yes, uap-core would be a separate Go module with its own lifecycle. Go also supports versionless imports based on Git commit references. Taking it one step further, you could even remove the "default" YAML data from uap-go, making it the end user’s responsibility to choose which version of the data they want to use. That would also be possible while keeping the default YAML, but then the YAML data would be bundled twice (default version + user version), which could unnecessarily bloat the application size.