I mean, git doesn't actually track diffs, so the diff/merge part is separate, and already supports plugins: just write a syntax-oriented diff/merge for git and tell git in your configuration files to use it for .py files or whatever... this isn't a git limitation.
Git actually does ship with parsers for different programming languages, I believe, because when you do a diff, it captions the changed lines with the function call they're from, etc. That said I've also used third-party "semantic diff" tools (generally for Windows) that have integrations with git. It's really nice when Github can't merge something, but you can, easily, locally, with a semantic merge/diff tool called from git.
Since golang includes sourcefile parser, it is possible to leverage those libs to reason about and automate stuff regarding sourcefiles. See "go fmt" for a start. Go sourcefiles can just be a storage layer for higher-end purposes then.
What is suggested in ancestor posts is to change storage format, although I think it better to prototype something like using the above first. Integrating into the object model directly, I suspect one would in the end want to design/evolve a language to build a platform specifically for that. You might end up with something similar to Smalltalk, so would need to think if that's the goal or if there's more to accomplish.
The higher order question is: What concerns need to be integrated, and what concerns need to be separated?
Integration may bring new powers, but also risks of evolutions into "big ball of mud".
Decoupling may bring freedoms and independency, but also risks of lack of coherency and unoptimal couplings.
What are the benefits of the current paradigm, and what are the disadvantages? CVS and text-files have worked for a very long time, is cross-platform and works beyond any single project scope. Maybe the golang-approach reaches some sort of optimal equilibrium.
