>excel is not usually treated as an engineering tool

This is a good point. I've seen C# & Python devs who read the release notes and adopt new features of C#\Python with alacrity while at the same time their Excel development work, which they spend considerable time on, evolves not at all. E.g., still using IF(ISERROR(...)) rather than IFERROR; VLOOKUP rather than INDEX(MATCH()); slow & brittle array functions rather than SUMIFS; employing many intermediate columns to clean out errors rather than using AGGREGATE(); doing things in VBA that they would never do in their primary programming language (v = Worksheets("pnl").Range("N22:N77").Value).

Ooh aggregate, I didn’t know of that. Seems like overkill for my use cases. And as you know, there is no kill like overkill

So, yes, there is content that exists. What does not exist are real-world examples of problem solving a la open source. As I said in another comment, debugging Excel is incredibly opaque (#NA) and most people will never find what they are looking for when they Google "=GETPIVOTDATA #NA error."

There is no GitHub for Excel workbooks where people build and extend generalized solutions that people can read, understand, and learn from. There is also a total lack of comments in Excel formulas (short of VBA custom functions) so good luck deciphering the 5 line SUMIF in the 10 year old model you inherited.

You can get many, many excel sheets and examples which highlight problems and provide solutions. You can dowload a 3D graphics engine in excel if you so desire, as well as more mundane examples and videos.

It’s not couched in engineering terms, but effectively a body of work and reference does exist to help people use excel - I’ve constantly used it to improve myself.

It is definitely not made by engineers and coders, but by normal people and excel jockeys.

Agreeing with you: just Google excel howto, then see results.