Actually, probably include the synthetic "init" function too.

I agree, it should really include all functions that have a body.

I don't know why "non-blank" was ever a concern; probably a symptom of my youthful zeal to complicate APIs in pursuit of trivial optimizations such as not generating code for functions that can't be executed. I wonder whether we can get away with quietly dropping mention of it and just stating:

"SSA provides SSA-form intermediate representation for all functions in the current package that have a body."

I agree it is a bit odd that buildssa does addAnons(f) but does not include package function literals. One option is to include the init function and call that "good enough" as everything is reachable. I don't find this quite satisfying though. I think it would be better to add package level functions to SrcFuncs. I feel like the current documentation would be for this to not include the synthetic "init", but to include all of the source level init functions init#1, etc. Maybe we should aim for an interface that is easy to use instead of following the current documentation to the letter?

For for _, I do not know how real this concern still is:

// SSA will not build a Function
// for a FuncDecl named blank.
// That's arguably too strict but
// relaxing it would break uniqueness of
// names of package members.