In the still active discussion of what Se is I think we've forgotten the primary tenet of the SE - the functional/structural duality.
"Systems Engineering" is a set of functions in the systems development process - encompasses different subfunctions such as requirements engineering, integration, V&V, technical coordination - see Sarah Sheards 12-role of SE for the reference. The core of functions contained inside SE is rather clear but there are "border skirmishes" in the areas of overlap with Industrial Engineering, PM and - yes - Systems Admin activities in the IT industry.
"Systems Engineer" is a structural element in the company/project organization (organizational position) that may (or may not) be assigned to perform SE functions. The company may call the position SE and may call it something else - for the person that fills the position the functionality and responsibility is what counts.
"Systems Engineer" as a person is something else - it's a matter of abilities and knowledge. David Snowman in his ASHEN model of knowledge distinguishes between various components of knowledge - Natural talents, certified Skills, gained Experience, mastery of the field Heuristics and access to the Artefacts of the professional field - reference books, special equipment (DOORS?) etc.
So the problem is of the degree of overlap between the specific persons's abilities (defined chiefly by herself), the responsibilities and authorities of the specific job position (as defined by the appropriate functions in the organization) and between the field of SE defined rather well by INCOSE or by SE degrees curricula.
We as SEs must not confuse functions, strructural elements and people!