Inconsistent behavior between CLI & XML parsing while handling leaf-list duplicate config

NETCONF
1

Summary:
This is a negative test case.
While trying to configure duplicate entries in leaf-list, CLI throws error ‘bad-value non-unique member’ error.
But, XML parser accepts the request, silently ignores the duplicate entry and create config with remaining unique entry.

Why is the CLI parser and XML parser duplicate-leaf-list handling is different?
Is this an intentional behavior?
If not, how to make it consistent behavior?

Yang ref:

   list profile {
        leaf-list features {
            type leafref {
                path <>;
            }
            max-elements "8";
            ordered-by user;
        }

CLI Error log:

(config)# profile abcde
(config-profile-abcde)# features [ F1 F1 ]
Error: bad value: "F1 F1" has non-unique members.

XML Working log:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <profile xmlns="...">
        <name>abcde</name>
        <features>F1</features>
        <features>F1</features>
        <features>F1</features>
      </profile>
    </config>
  </edit-config>
</rpc>
##

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="102">
  <commit/>
</rpc>
##

Running-config after XML commit:

profile abcde
 features [ F1 ]
exit
2

Leaf-lists entries for configuration data are required to be unique so in that sense, the behavior of each interface conforms to the RFC. However, you will often find that the CLI has the opportunity and expectation of higher levels of logic to help the user so the code can end up being different. That is probably the main reason. On the other hand, it does sound like significant difference that one accepts it and the other does not.