AVR Freaks

Never heard of the "mop up" header before (neither the header as such, nor the specific expression).

Anyway, I'll stand by my statement above. Having the specific port as part of the name for something that "just" represents a pin number within a port is redundancy in code and should be avoided.

To try to make my thinking clear to the OP:

If something is on PORTB pin 2 then that should be stated separately and neither fact should be "doubled". I.e.

#define PORT_SOMETHING PORTB
#define PIN_SOMETHING 2

Having the port stated as part of the pin stuff just risks a missed update if something is moved to another port but same pin number within that port. i.e.

#define PORT_SOMETHING PORTB
#define PIN_SOMETHING PORTB2

and then moving to PORTD but still pin 2 within that could end up

#define PORT_SOMETHING PORTD
#define PIN_SOMETHING PORTB2

which will work just fine - but someone reading the code might be very confused. Is something on PORTB or PORTD? E.g. that someone might want to measure a signal between the AVR and something and happens to see the PORTB2 first and attaches his oscilloscope to that pin. Nothing! No signal at all. Depending on luck, experience and phase of the moon it can take that person 10 seconds or several hours to discover what is the truth.

Using the style I prefer (first code snippet above) this ambiguity will never occur. And you get to use the same symbolic name for the pin number regardless of if you're accessing the PORT, PIN or DDR register.

Nice. Clean. Less risk for bugs and/or confusion.

Having the port name as part of the pin number symbolic name does not make anything clearer. Just say "no". ;-)

I like the generic bit masks and bit positions as these defined in iotn1616.h.  Have often seen, and used, similar in ARM code.

// Generic Port Pins

#define PIN0_bm 0x01
#define PIN0_bp 0
#define PIN1_bm 0x02
#define PIN1_bp 1
#define PIN2_bm 0x04
#define PIN2_bp 2
#define PIN3_bm 0x08
#define PIN3_bp 3
#define PIN4_bm 0x10
#define PIN4_bp 4
#define PIN5_bm 0x20
#define PIN5_bp 5
#define PIN6_bm 0x40
#define PIN6_bp 6
#define PIN7_bm 0x80
#define PIN7_bp 7

So, show us the definition of ABC. (Is there one?)

Now, you might ask why they named it such - breaking the pattern that holds for e.g. PORTB/PORTBn and PINB/PINBn. I don't know. It doesn't make sense to me either.

Because avr-libc did before we started to generate the header files. So, we keep the compatibility (even though as you and Cliff says, doesn't make much sense in the greater picture).