COMPILER_TYPE won't work in this file. sys.mk is loaded before Makefile is. We've tried to include bsd.compiler.mk this early but ran into problems.

Is this convention established elsewhere too?

We're moving things out of sys.mk. bsd.compiler.mk was one thing. bsd.cpu.mk is also on the way out too.
I hate to sound like bde here, but why do these need to be global to everything? There's no %POSIX protection
though I haven't checked to see if it's part of a bigger posix section.

Why does this need to be global?

These would be better in bsd.init.mk or something similar. You can't test COMPILER_TYPE here.

Alternatively, make them unconditional. If the compiler doesn't understand things, it will just
fail. It will fail without the tests anyway.

I really want to merge the suffix transformation rules, perhaps into bsd.suffix.mk, and include from bsd.obj.mk.

Referring to the suffix or the comment? If the suffix, I was attempting to match the .po and .So convention, i.e., "special kind of .o file". If the comment, I was attempting to match the following line that describes the .So file.

Moving things into bsd.suffix.mk sounds great: I was a bit perturbed by the need to modify .SUFFIXES in two files. Does this mean that I should hold off with this patch until other changes settle out?

I'd be happy to make these things unconditional, but it sounds like things are moving around in the meantime?

I don't know of any specific standard extensions and they wouldn't really work anyway because IR is combined multiple times before it is used. In this case we're making it us as we go along.

The overall problem (not apparent in this patch because its just part of a larger picture) is that we need to specify multiple different ways to get from a collection of C files to a program. For example, some paths might look like *.c->*.llo->*.o->${PROG} while others might be *.c->*.llo->*.lla->${PROG}. Make isn't good to letting you control which path you take to get from *.c to ${PROG} so a fair bit of ugly extension hacker is required to produce a flexible system.

Aside, are we aware of any actual use of .C for C++ files?

Nope, I've never seen .C in the wild. One "source" claims that Stroustrup used to use .C, which seems to jive with the implication of his style guide, but I suspect that .C has been uncommon since Windows 3.1 started getting popular. :)

In fact, Stroustrup now recommends .cpp though the CppCoreGuidelines project.

I suppose they don't necessarily need to be global. I was just trying to mimic the structure of PO_CXXFLAGS: defined in sys.mk and used in bsd.lib.mk (and, in the case of IR, bsd.prog.mk).

I've personally worked on three different projects that used .C for C++ files. One from 1990-1993, one from 1995-1996, and one in 1998. The deja-gnu test suite for C++ (as recently as 4.6) and there's about 100 patch files in ports for files ending in .C.