BLAS.jl should be internally divided into … and generic/fallback implementations (which could hopefully eventually become fast enough that whether to include a vendor blas is just a configuration option).
It seems to me that all of linalg/matmul.jl should be part of BLAS.jl, as well as the BLAS-like parts of linalg/generic.jl.
Like Andreas said, I was suggesting to have “BLAS” as being wrappers for an external library that makes matrix multiplication faster. Not loading the the BLAS submodule shouldn’t mean generic matrix multiplication is impossible - I don’t see the upside of that.
(For example, it would be interesting to build Julia with less dependencies and still have generic code work, e.g. this. I do realize we don’t (yet) have generic replacements for everything in LAPACK, ARPACK and SuiteSparse, but that’s not a reason not to have a modular system like that common in large systems of packages (MathProgBase is one example, but I’m not that familiar with it)).