Guidelines to a decent support of surrogate key implementation

Lately, I have brought emphasis on the subject of concatenated keys vs
addition of column. I have noticed then that the thread quickly
turned to a debate about the failure of current dbms's to bring a
decent support of surrogate key implementation. From what I observe 3
line of thoughts trends appear:

LINE1> People who think that surrogate key should be an internal
physical mechanism to the dbms and invisible to designer who could
focus on the logical selection of primary keys
LINE2> People who think that a trdbms should allow the designer to
have some control
LINE3> People who think there is nothing wrong with current surrogate
key implementations

I personally belong to first category.

What do you think are the Pro/Cons of each approach? Here is mine:

LINE1>
PRO
Designer can focus better on logical design. Less error prone in
key implementation
Independence between the logical and physical layer is implemented
at design time.

CON
Surrogate key implementation becoming internal addressing pointers,
users can not find any more familiarity in surrogate keys. Assuming
familiarity is an advantage, that would become a CON.

LINE2>
PRO
Familiarity
CONS
Introducing a part of subjectivity in key generation process

LINE3>
PRO
?
CONS
Keys implemented are not primary key implementations
Product oriented bias for definition of keys
All consequences arising for not having identity


Thank you for bringing your insights onto this theme. Thank you for
respecting the frame/structure for conciseness's sake.

Regards all...

.