Archimate 3: Application Process vs Application Process - What is the Distinction? (Please)

Overview

I'm trying tease out the distinction between an Application Process and an Application Function in Archimate 3 and how they might be used differently in a model. Below I have set out my thought process in trying to figure this out.

I'm not sure I have succeed particularly, But I wonder if the Archimate community will have some better insights in to this!

Analysis

From the meta-model perspective there seems to be no difference, which suggests they can be used inter-changeably, in theory.

Looking at the text of the specification ...

For a Application Function the differentiating aspects, I've concluded might be:

• (1) "An application function represents automated behavior that can be performed by an application component."
• (2) "An application function describes the internal behavior of an application component."
• (3) "The name of an application function should preferably be a verb ending with “ing”; e.g., “accounting”."
• (4) "An application function may realize one or more application services"

And for Application Processs:

• (5) "An application process represents a sequence of application behaviors that achieves a specific outcome."
• (6) "An application process describes the internal behavior performed by an application component that is required to realize a set of services"
• (7) "The name of an application process should clearly identify a series of application behaviors;"
• (8) "An application process may realize application services."

(9)Also, the example in 9.3.6 may yield some insights.

From these I draw these conclusions from each aspect:

• (1) & (2) seem to say the pretty much the same thing: a given function is associated with a single component.
• (3) The naming convention suggests (to me) that the a function represents some class of behaviour rather than something more distinct. 
• (4) Some functions are just internal to the component.
• (5) A process defines a chain potentially of functions, events, services, and other sub-processes that has a distinct purpose.
• (6) ".. a set of services" - a process must expose it's behaviour externally. it's behaviour is not so distinct ("..a set..") which contradicts the point above.
• (7) Does help at all really.
• (8) The behaviour in a process may be internal to the component - if it may realize services then I guess it also may not. If so, this contradicts (6)
• (9) The process shown uses some other services, but gives no indication of "sequence" other than natural left to right reading. (It pretty much fails to
• meet all the naming conventions for most of the components. AFAICT!) The "Prepare Quotation" and "Finalize Purchase" seem to define quite distinct pieces of 
• behaviour, which contradict my conclusion on (3). the behaviour in "Obtain Travel Insurance" does not "realize a set of services" as it is required in (6) - but allowed in (8).

Opinion & What to Do

To summarize, to me the specification is confusing and contradictory. Given that the specification is unlikely to change any time soon I'm inclined to impose a defined approach to obtain some consistency in usage across the company.

The following approaches are under consideration:

• Just use function and process inter-changeably.
• Just ignore either function or process (like this problem didn;t existing in Archimate 2)
• Assign distinct roles for process and function: like a process may contain other "child" processes and functions ; a function may have no child processes. All other relationships are allowed.