looking at the calling forms for Matlab's and Octave's assert, I think Octave currently is a superset of what Matlab's does.

 -- assert (COND)
 -- assert (COND, ERRMSG)
 -- assert (COND, ERRMSG, ...)
 -- assert (COND, MSG_ID, ERRMSG, ...)
 -- assert (OBSERVED, EXPECTED)
 -- assert (OBSERVED, EXPECTED, TOL)

the matlab version uses the first four calling forms.  the last two are what we regularly use in BISTs, and are NOT supported by matlab's assert.

the matlab & 1st set of octave forms just check for COND to return true.  so

>> assert(true)

>> assert(false)
error: assert (false) failed
error: called from
    assert at line 107 column 11

OT: how ours differentiates the different forms is a bit odd. 

>> a = 2;  assert(a,"a string?")
error: ASSERT errors for:  assert (a,"a string?")

  Location  |  Observed  |  Expected  |  Reason
     .            2        a string?     Expected string, but observed number

>> a = true;  assert(a,"a string?")

>> a = false;  assert(a,"a string?")
error: a string?
error: called from
    assert at line 109 column 11

All that said, as Markus said this bug report is really just limited to the Octave unique calling form. So no need to worry about mathworks.

I realize the issue can be avoided by specifically doing an assert(issparse(a),issparse(b)) test rather than relying on setting off assert(a,b) if their sparseness is different. I thought it odd that we ran those tests, though, only if no tolerance was specified.

I didn't know if the issue had to do with the complexity of performing the subtraction and eps comparison for the different types.  (perhaps related to the need to do implicit expansion with eps and bug #63281)

Matlab's `assert` is different from Octave's implementation:
https://www.mathworks.com/help/matlab/ref/assert.html

I don't think this was for compatibility reasons.

looking at this more closely, it seems that only the assert codepath without tol performs the sparseness check (around line 247), just after a comment: ## Without explicit tolerance, be more strict."
other conditions get ignored as well:

>> assert([1 2 3],complex([1 2 3]))
error: ASSERT errors for:  assert ([1, 2, 3],complex ([1, 2, 3]))

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         real != complex

>> assert([1 2 3],complex([1 2 3]),eps)

>> assert([1 2 3],single([1 2 3]))
error: ASSERT errors for:  assert ([1, 2, 3],single ([1, 2, 3]))

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         Class double != single
>> assert([1 2 3],single([1 2 3]),eps)

>> assert([1 0 1],logical([1 0 1]))
error: ASSERT errors for:  assert ([1, 0, 1],logical ([1, 0, 1]))

  Location  |  Observed  |  Expected  |  Reason
     ()           O            E         Class double != logical
>> assert([1 0 1],logical([1 0 1]),eps)

so, this is by design? is it really problematic to have these cases do type checking when a numerical tolerance is given?