[Krei-se]

You are very close. CT is about structure, not which problem this structure solves. Compilers are closest in what i can think of in this regard: They don't resolve one problem domain, but many. Which one you apply it on is up to you.

One tool for one job is a simple rule you can adapt as a systems architect allowing you to build clear structure for the problem domain you come across. esbuild comes to mind as an example - the job was solved before, but keeping one purpose in mind and writing it from scratch solves the problem WAAAY faster.

So no, no problem is solved inside the domain of product software development, but outside of it, you as a developer can (if you want and for speed) derive any structure from the absurd function instead of combining foreign frameworks.

[Koshkin]

> CT is about structure

No, this is exactly what CT is not about. (It is about morphisms.)

[Krei-se]

From Milewski: "That’s because category theory — rather than dealing with particulars — deals with structure. It deals with the kind of structure that makes programs composable."

And he is right, because morphisms may or may not preserve structure. If you want to nitpick and create structure from the absurd function morphism - then yeah, so I think a discussion about this gets tedious. The more you look into the matter the more structure / data and morphisms merge and your point feels more like an invitation for the newbies to have a mental breakdown.