[model_edit] The Library Browser name `Integrator, Second-Order` resolves to a different block (`Integrator`), while the web documentation name for the same block resolves correctly

[shafiul]

Bug Report

Summary

Simulink/Continuous contains a block that MathWorks documents under two different names:

surface	name
Simulink Library Browser	Integrator, Second-Order
Reference documentation (page)	Second-Order Integrator

Passed to model_edit, the two names behave oppositely:

• Second-Order Integrator → SecondOrderIntegrator, 2 output ports. Correct, 95% confidence.
• Integrator, Second-Order → Integrator, 1 output port. A different block, 65% confidence.

Both return status: ok. model_check reports healthy on the result. The toolkit's own
building-simulink-models skill instructs callers to use the Library Browser name — the one that
fails.

The delivered Integrator is not a variant of the requested block. They are separate built-in types
with 1 vs 2 output ports and 22 vs 15 dialog parameters, of which only 2 are shared.

Measured

#	string passed as type	source of that name	delivered BlockType	out	conf	correct
1	Integrator, Second-Order	Library Browser	Integrator	1	65%	✘
2	Second-Order Integrator	documentation	SecondOrderIntegrator	2	95%	✔
3	Integrator, Second-Order Limited	Library Browser	Integrator	1	65%	✘
4	Second-Order Integrator Limited	documentation	—	—	—	✘ NOT_FOUND
5	SecondOrderIntegrator	internal type name	SecondOrderIntegrator	2	—	✔
6	simulink/Continuous/Integrator, Second-Order	full path	SecondOrderIntegrator	2	—	✔
7	Integrator Second-Order	—	Integrator	1	65%	✘

Rows 5 and 6 return no warning. Rows 1, 2, 3 and 7 warn.

For the Limited variant, neither documented name works: the Library Browser name silently returns a
plain Integrator (row 3), and the documentation name is refused (row 4).

Verbatim responses

requested: "Integrator, Second-Order"
status: ok
warnings:
  - warning: Using 'Integrator' as best guess for 'Integrator, Second-Order' (65% confidence).
    Verify this is correct. Alternative matches: DiscreteIntegrator, SecondOrderIntegrator

requested: "Second-Order Integrator"
status: ok
warnings:
  - warning: Using 'SecondOrderIntegrator' as best guess for 'Second-Order Integrator' (95% confidence).
    Verify this is correct. Alternative matches: DiscreteIntegrator, Integrator

requested: "Second-Order Integrator Limited"
status: error
error_code: NOT_FOUND
message: error: 'Second-Order Integrator Limited' not found. Try: DiscreteIntegrator, SecondOrderIntegrator

In row 1 the correct block, SecondOrderIntegrator, is present in the alternatives list and was ranked
below Integrator.

Minimal reproduction

m = 'repro'; new_system(m); load_system(m);
model_edit(m,'root','[{"op":"add_block","type":"Integrator, Second-Order","name":"A"}]','full');
model_edit(m,'root','[{"op":"add_block","type":"Second-Order Integrator","name":"B"}]','incremental');
get_param([m '/A'],'BlockType')   % 'Integrator'             <- Library Browser name
get_param([m '/B'],'BlockType')   % 'SecondOrderIntegrator'  <- documentation name

Behavioural consequence

The Second-Order Integrator integrates its input twice; Integrator integrates once. A model that
uses only the first output — which is ordinary, since the block exposes dx separately and it is often
unused — wires without error and simulates without error.

Task: integrate a constant acceleration of 1 for 3 s to obtain position (x = ½at² = 4.5).

model	result at t=3
built from Integrator, Second-Order	3.0
built from the correct block, identical wiring	4.5

The delivered value is the velocity, not the position. model_check reports healthy.

If the task also uses the second output, model_edit reports the problem clearly
("Port out2 does not exist … (has 1 outport(s))"). The defect is therefore visible only when the
lost output is used, and silent otherwise.

Why this appears to be a defect rather than a naming preference

1. The failing name is the one the toolkit's own guidance specifies. The shipped
building-simulink-models skill states: "Use the block's display name in the type field. Do not
construct or guess library paths" and "Use the display name as it appears in the Simulink Library
Browser."

2. The documented recovery path does not trigger. The same skill states: "If model_edit returns
INVALID_TYPE: Fall back to the full library path." Row 1 returns status: ok, so a caller following
the documented procedure receives no signal.

3. Both failing and succeeding names are MathWorks'. This is not a matter of an imprecise request:
row 1 and row 2 are the same block under its two official names, and only one resolves.

4. The correct block was considered and ranked second. It appears in row 1's alternatives list.

5. Where NOT_FOUND is emitted, its suggestions point away from the requested block. Row 4 offers
DiscreteIntegrator and SecondOrderIntegrator; neither is the limited variant that was requested.

Suggested remedies (any one would address the reported behaviour)

1. Resolve a string that exactly matches a documented block name — from either the Library Browser
   or the reference documentation — to that block, before fuzzy matching against internal type names.
2. When the resolved block differs in type or interface from an exact-matching documented name, report
   that specifically; the present warning concerns only the guessed type name.
3. Emit INVALID_TYPE when resolution is by best guess and the request exactly matched a documented
   block name, so the documented fallback to a full library path can trigger. An error code alone is
   not sufficient: row 4 shows NOT_FOUND already firing for Second-Order Integrator Limited, and
   the suggestions it offers (DiscreteIntegrator, SecondOrderIntegrator) are drawn from the same
   ranking that failed, so a caller following them arrives at the wrong block by a second route.

Relationship to existing issues

• model_edit resolves bare block names to the built-in source, silently diverging from documented library defaults #53 — bare type names bind the built-in source, diverging from documented library defaults. That
  is a configuration divergence within one block type. This report concerns a different block
  type being delivered: 1 output port instead of 2, and 2 shared dialog parameters out of 15 and 22.

  A fix for model_edit resolves bare block names to the built-in source, silently diverging from documented library defaults #53 cannot address this, and that is checkable rather than arguable. The built-in and
  library forms of the delivered block are identical:

  % 0 of 15 dialog parameters differ
  built-in/Integrator   vs   simulink/Continuous/Integrator

  So if model_edit bound every name to the library source, Integrator, Second-Order would still
  resolve to Integrator and deliver a block identical to the one it delivers today. Source binding
  is an axis with no effect on this case; the failure is in which block the name resolves to.

• model_edit adds Relational Operator with default Operator '>=', but Simulink library default is '<=' — silent semantic inversion #50 — a divergent Operator default on Relational Operator. Exact name, wrong default.

Additional Context

No response