Agree upon terminology for configurable fields

Suppose configurable is not suitable here because of configurables (ConfigEntity) which would lead to misunderstanding
Extendable makes more sense

The term "configurable" is not used at all by ConfigEntity, that's "configuration entity".
We just still use it in issue tags for legacy reasons, but we can update those.

When this gets resolved, there will be something todo related it #1498674-82: Refactor node properties to multilingual.

Another problem with "configurable fields" is that the other ones - formerly known as 'properties' - to some extent are to be configurable as well. As effulgentia put it in #1188394-50: Make title behave as a configurable, translatable field (again):

the goal for D8 is for properties to have all the capabilities that fields currently have, and for the only thing that is special about fields is that they can be created/removed by administrators.

It is debatable whether storage might be an additional distinction. At least currently, 'properties' by default also live in the {entity_field_data} table (label) resp. for nodes in the {node_field_data} table (title; uid; status; created; changed; comment; promote; sticky). But even that distinction might be blurred at a later point, see fagos comment #1346214-1: [meta] Unified Entity Field API.

So IMHO we need to make clear what exactly we're talking about:
Properties like 'status', 'created' or sticky clearly are properties. Technically speaking, they will be translatable but not very much configurable. 'Title' is less obvious - it will be both translatable and to a large extent configurable.
The ultimate distinction remains IMHO, that 'properties' are fields that are "hardcoded" by the entity and that might live in the main {entity_field_data} table or not. Even if they might be more or less configurable, their configurability is limited by the entity definition and at least they might not be completely removed by configuration resp. the admin.
Whereas 'fields' are configuration resp. admin defined fields that always live in normalized tables as managed by the Entity Field API, and which are always fully configurable and removable.

So the distinction is rather small and blurred, so we need to figure out where it is needed at all.
UI-wise it should be enough to state that on a specific property some aspects of configuration are "locked by the entity definition".
Code-wise, I'm not sure, two separate terms would cut it, because if we look at title vs. created, we need to be even more specific regarding what can be configured on a specific 'property' and what can't. While 'title' can be reordered with the other fields, 'status' or 'created' aren't even listed or displayed.

We could possibly reflect this variation by sticking with 'property' for the latter 'real properties', call fields like 'title' an "entity defined" field with limited configurability and our regular fields "configuration defined", fully configurable fields. So there were three categories with a terminology that unfortunately isn't very concise, but - if I get everything right - at least very precise. :)

Technically, changing the weight or visibility of a "base field" is not configuring the field itself, since display / form settings live in EntityDisplay and EntityFormDisplay objects.
So the "base field" themselves are fully non-configurable. The things that get configured are stuff that "talk about" the fields, not the fields themselves.

I agree that the distinction "what is part of the field definition itself, vs. what is part of EntityDisplay and EntityFormDisplay config entities" is mostly abstracted away when you look at the UI.
But the "Base field" / "Configurable Field" terminology lives primarily in code, and would probably not surface in the UI anyway.
So the terminology agreed so far still makes sense IMO.

That's true, at least code-wise, form and display settings aren't relevant. So what is remaining to be non-configurable for all 'base fields' are the field type and aspects like number of values and maximum length which obviously need to stay locked for 'base fields'.
Translatability however has to be configurable at least for some 'base fields' (title), so it can be no distinction between 'base fields' and 'configurable fields'.

Properties like 'status', 'created' or sticky clearly are properties.

I'm actually not so sure there's a meaningful difference between node.created and node.title in terms of how property-like vs. field-like they are. Per #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title, node.created is formatted and displayed, just like title. However, I agree that we might want to consider a meaningful distinction between the stuff currently stored in {node} (e.g., nid, vid, type, landcode, uuid) and the other stuff currently stored in {node_field_data} (e.g., title, uid, created, sticky, etc.). And among the latter group, maybe there's some important difference between some of them (e.g., 'status') and the others. But if so, what is that important difference? Very related to that: #2010930-2: [META] Apply formatters and widgets to rendered entity base fields (all besides node.title). Please provide feedback there to help on that issue, and maybe in the process, we can gain clarity into this issue.

hum, what about "Custom fields" and "Base fields"

KISS

so it would be:

"Custom field", "Extendable/Configurable entity type", and "Base field".
as per https://drupal.org/comment/6627784#comment-6627784

I think we're done here ?

No answer, temptatively closing :-)

"Custom fields" vs "Base fields" sounds good here.