Note that this doesn't touch merely "pcs resource create", but also
"pcs resource op" family of commands.

If I understand correctly (taking into account bug 1382597 comment 8), the proposal is:

[vm-rhel72-1 ~] $ pcs resource create webserver ocf:heartbeat:apache op monitor interval=10 op monitor interval=20 statusurl=http://localhost/server-status
[vm-rhel72-1 ~] $ pcs cluster cib|grep 'primitive.*id="webserver"' -A 11
      <primitive class="ocf" id="webserver" provider="heartbeat" type="apache">
        <operations>
          <op id="webserver-monitor-interval-10" interval="10" name="monitor"/>
          <op id="webserver-monitor-interval-20" interval="20" name="monitor">
            <instance_attributes id="webserver-monitor-interval-20-instance_attributes">
              <nvpair id="webserver-monitor-interval-20-instance_attributes-statusurl" name="statusurl" value="http://localhost/server-status"/>
            </instance_attributes>
          </op>
          <op id="webserver-start-interval-0s" interval="0s" name="start" timeout="40s"/>
          <op id="webserver-stop-interval-0s" interval="0s" name="stop" timeout="60s"/>
        </operations>
      </primitive>
      
The 'statusurl' option is accepted because is among parameters of the resource agent. When some option is not among parameters you proposing use the --force flag. Something like this:

[vm-rhel72-1 ~] $ pcs resource create webserver ocf:heartbeat:apache op monitor interval=10 op monitor interval=20 a=b
Error: invalid resource operation option 'a', allowed options are: OCF_CHECK_LEVEL, description, enabled, id, interval, interval-origin, name, on-fail, record-pending, requires, role, start-delay, timeout. It could be used as an instance attribute of operation, use --force to override.
[vm-rhel72-1 ~] $ pcs resource create webserver ocf:heartbeat:apache op monitor interval=10 op monitor interval=20 a=b --force
[vm-rhel72-1 ~] $ pcs cluster cib|grep 'primitive.*id="webserver"' -A 11
      <primitive class="ocf" id="webserver" provider="heartbeat" type="apache">
        <operations>
          <op id="webserver-monitor-interval-10" interval="10" name="monitor"/>
          <op id="webserver-monitor-interval-20" interval="20" name="monitor">
            <instance_attributes id="webserver-monitor-interval-20-instance_attributes">
              <nvpair id="webserver-monitor-interval-20-instance_attributes-a" name="a" value="b"/>
            </instance_attributes>
          </op>
          <op id="webserver-start-interval-0s" interval="0s" name="start" timeout="40s"/>
          <op id="webserver-stop-interval-0s" interval="0s" name="stop" timeout="60s"/>
        </operations>
      </primitive>
      
But how could be achieved this?

<op id="webserver-monitor-interval-20" interval="20" name="monitor">
  <instance_attributes id="webserver-monitor-interval-20-instance_attributes">
    <nvpair id="webserver-monitor-interval-20-instance_attributes-interval" name="role" value="some-specific-value"/>
  </instance_attributes>
</op>

If you try

[vm-rhel72-1 ~] $ pcs resource create webserver3 ocf:heartbeat:apache op monitor interval=10 op monitor interval=20 role=master

you get

<op id="webserver3-monitor-interval-20" interval="20" name="monitor" role="Master"/>

Ok, it is artificial. But I gues it will be better to separate operation attributes from instance attributes explicitly. Something like this:

[vm-rhel72-1 ~] $ pcs resource create webserver ocf:heartbeat:apache op monitor interval=10 op monitor interval=20 op-params statusurl=http://localhost/server-status

re [comment 2]:

> But how could be achieved this?
> 
> <op id="webserver-monitor-interval-20" interval="20" name="monitor">
>   <instance_attributes id="webserver-monitor-interval-20-instance_attributes">
>     <nvpair id="webserver-monitor-interval-20-instance_attributes-interval" name="interval" value="some-specific-value"/>
>   </instance_attributes>
> </op>

^ changed "role" instance attribute into "interval", which was likely
  intended per the attribute id


First, let me elaborate on how pacemaker itself handles cases like this:

1. direct op vs. instance_attribute source clash
   - OCF_RESKEY_CRM_meta_X carries op-sourced counterpart, OCF_RESKEY_X
     carries instance_attributes-sourced one (agents are expected to
     immediately respond only to OCF_RESKEY_X encoding of parameters)
   - for the purpose of triggering the action, pacemaker only follows
     op-sourced value (note: "interval" at op-level is mandatory
     to conform to the schema)

2. instance_attribute as the only source
   - both OCF_RESKEY{_CRM_meta,}_X carry instance_attributes-sourced
     value
   - for the purpose of triggering the action, pacemaker does _not_
     follow this instance_attributes-sourced value

3. op as the only source
   - at least in some cases (start-delay) not even OCF_RESKEY_CRM_meta_X
     carries op-sourced value
   - apparently, for the purpose of triggering the action, pacemaker does
     follow this op-sourced value


In other words, pacemaker does _not_ turn the hypothetical conflict into
anything real.


On the other hand, there's indeed a real clash when parameter of
resource agent shadows the native op-level one, in:

A. distinguishing the intended destination when entering such
   parameter
   - pcs resource create (as mentioned at the bottom of [comment 2])
   - "pcs resouce op" family of commands

B. distinguishing the source when listing operations
   - pcs resource --full


As it is expected that there will be no clash most of the time, I'd
rather see special prefix (colon?) devised for explicit confirmation
that the instance_attributes level is intended.

Hence, the alternative modification of the command from [comment 2]
could be:

$ pcs resource create webserver3 ocf:heartbeat:apache \
  op monitor interval=10 \
  op monitor interval=20 :role=master

... "pcs resource --full" could then be explicit like that, too:

> Resource: webserver3 (class=ocf provider=heartbeat type=apache)
>  Operations: monitor interval=10s
>              monitor interval=20s :role=master
                                    ^

re [comment 0]:

> - ditto for other operations, but require --force

As an exception, allow specifying trace_{ra,file} parameters
(see [bug 1402374]) as instance_attributes regardless -- it's
actually quite helpful to focus on debugging/tracing just
a particular operation.

Another note:

There's likely a bug in pacemaker leading to different treatment of
meta_attributes per-op vs. op_defaults:

- per-op:
  this only leads to carrying OCF_RESKEY_CRM_meta_X to the agent
  being executed 

- op_defaults:
  ditto, _but_ also acutally takes those values into account for
  action processing internally

Quick test using "pcs resource restart httpd":

<resources>
  <primitive class="ocf" id="httpd" provider="heartbeat" type="apache">
    <operations>
      <op id="httpd-monitor" name="monitor" interval="30s">
        <meta_attributes id="httpd-monitor-meta">
          <nvpair id="httpd-monitor-meta-start-delay" name="start-delay" value="41s"/>
        </meta_attributes>
      </op>
    </operations>
    <meta_attributes id="httpd-meta_attributes"/>
  </primitive>
</resources>

-->

> httpd successfully restarted

vs.

<op_defaults>
  <meta_attributes id="op_defaults">
    <nvpair id="op_defaults-start-delay" name="start-delay" value="41s"/>
  </meta_attributes>
</op_defaults>
<resources>
  <primitive class="ocf" id="httpd" provider="heartbeat" type="apache">
    <operations>
      <op id="httpd-monitor" name="monitor" interval="30s"/>
    </operations>
    <meta_attributes id="httpd-meta_attributes"/>
  </primitive>
</resources>

-->

> Error: Could not complete shutdown of httpd, 1 resources remaining
> Error performing operation: Timer expired
> 
> Set 'httpd' option: id=httpd-meta_attributes-target-role set=httpd-meta_attributes name=target-role=stopped
> Waiting for 1 resources to stop:
>  * httpd
>  * httpd
> Deleted 'httpd' option: id=httpd-meta_attributes-target-role name=target-role


Hence, I am not getting what's the purpose of per-op meta_attributes.

Disregard [comment 6] (see [bug 1470223 comment 1]) and point 2.
from [comment 3]: in fact pacemaker indeed takes instance_attributes
into account for the purpose of triggering the action.

But that's unfortunate, as it allows for ambiguities (is some parameter
meant for pacemaker inner working, is it to be passed to the agent,
or both -- point 2. is actually this very case).

Will reopen [bug 1470223] to at least avoid that likely undesired
ambiguity.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.