Currently, community/openblas (unlike aur/openblas-lapack) doesn't build and provide OpenBLAS's optimized lapack neither their C bindings (cblas and lapacke).

However, building and providing lapack and the C bindings has multiple advantages.
1. Providing the C bindings would solve bugs raised in Arch:
* https://bugs.archlinux.org/task/59046
* https://bugs.archlinux.org/task/63054
2. OpenBLAS optimized some LAPACK routines that would become available by providing lapack (and lapacke). See also https://bugs.archlinux.org/task/62558.
3. It's both the default upstream configuration and what mainstream users expect and test (as it's what they do when they vendor OpenBLAS in pip wheels and conda packages).
* upstream OpenBLAS (https://github.com/xianyi/OpenBLAS/blob/develop/Makefile.rule)
* NO_CBLAS=1, NO_LAPACK=1, NO_LAPACKE=1 are all commented
* Julia: https://github.com/JuliaLang/julia/blob/master/deps/blas.mk
* (BTW, it should remove the need for our julia-system-cblas patch to community/julia)
* NumPy: https://github.com/numpy/numpy/blob/master/tools/openblas_support.py
4. Clearer for users: they either have BLAS and LAPACK from Netlib, or BLAS and LAPACK from OpenBLAS. No mix. Currently when a user installs openblas, they only get blas, while cblas, lapack, and lapacke are provided by extra/lapack (from the Netlib reference implementation).
5. Building and shipping packages in their entirety goes with the Arch principle of simplicity.

For these reasons, I hope community/openblas can build and provide cblas, lapack, lapacke (and aur/openblas-lapack retired). I can't think of any downsides, neither did I found any while researching the issue nor while using aur/openblas-lapack for years. Thanks for your work and considerations!