[eviks]

> they want to provide packages that cover as many usecases as possible.

How would this macro exclude the coverage of other use cases? The language primitives would still be there to do the original code

> There is no central body

That's true for plenty of other syntaxes that at the same time aren't like this

[mr_mitm]

As I said: Maybe you want to specify a different placement option like `b` instead of `t`. Maybe you don't want the label equal to the file path, in particular if you happen to include an image twice.

Or you don't want it centered. Or you want several images in one figure environment arranged in some way. Or you want to scale the included image to fit only 70% of the page width. Or maybe you want to rotate the included image by 90 degrees. Many more use cases are imaginable.

You could define the macro to cover all of this, but then you might as well just write the original code.

[eviks]

And as I replied: how does any of this *prevent* you from "cover[ing] as many usecases as possible" given that writing the original code is always an option?

[smaudet]

Namespaces and constraints.

The first (namespaces) contrast speed (brevity) and specificity (verbosity). Namespacing (long names) are great when you don't have a good idea the full scope - putting your library in namespace means you generally never have to be concerned that terms will overlap.

Macros tend to be the opposite - short, in global namespace, with little flexibility. They constrain the possible output by focusing on a certain goal - this is the point of the macro usually, to avoid some common pitfall without being overly verbose.

If you combine the two, you have a problem - either the macro dictates your preference, or many different macros must exist which, usually being brief or in pursuit of similar goals, will result in namespace collisions.

So of course you can define them, but generally this is better suited towards a specific use case or organization.

Or at least that's the idea. I'm not sure some standard approachable macros are a bad thing, as long as you can redefine them later or pick and choose, but I do get the point of "why not", because they don't want to constrain the language itself. The irony is other systems do this for them and tex becomes more an outsider thing and systems like markdown are far more constrained...

On the other hand there is no way to make everyone happy, and I respect the Tex author decision to opt for a less-is-more strategy wrt to offering building blocks only not templates.

You are of course free to build your template library, and make it popular, but be forewarned that likely whatever it is popular at doing (say, writing science articles), will affect what TeX is used primarily for. Which is the "why".