Looks like a good start.

• Your case switching check is identical for rank 0 to 1 and 1 to 2. A dependency on the rank will be necessary to differentiate. For a ufl form a you can access the rank as a.rank. I now saw the arguments check.
• To ensure your code works and to simplify development unit tests would be good to add, for example in test_forms.py. (The rank 1 to 2 case seems to be only unit tested through the assembler at the moment, would be good to also add a small unit test for this case)

thanks @schnellerhase and @jorgensd

I found no rank() method, so I used the more cumbersome check with len(F.arguments())

While adding tests, I realized there were more situations where the user can supply bad inputs and get obscure errors (or unintended results silently), so I have been more comprehensive when checking the inputs.

For example, before you could wrongly pass trial functions to derive functionals, and it would still return a form (or Nones) without complaining, asufl.derivative seems quite silent. I’ve also made sure that incorrect arguments don't exit derivative_block with an unhelpful error. After this,derivative_block grew, so its body is now grouped in small functions to make it more readable.

For consistency, I’ve also replaced the asserts with ValueError. And I’ve used ValueError even in cases when the strictly correct exception should be TypeError, in order to avoid more extra conditions (assuming that users won’t care and that they won't be dealing with these exceptions at such level of detail). I was not quite sure about the preference on this point though

Could you let me know how it looks, if the new checks do indeed belong here, or any other feedback or thoughts?

This looks pretty good but I think it's a bit 'strongly typed/overly checked' with if statements - shouldn't a lot of these already be picked up lower down in UFL?

This looks pretty good but I think it's a bit 'strongly typed/overly checked' with if statements - shouldn't a lot of these already be picked up lower down in UFL?

I've removed now some of the checks as suggested above. I'm happy to remove the rest of those suggested, but I left a question in an inline comment that I think needs to be resolved first

I marked as "resolved" the comments that I believe require no further action, but please let me know if anything doesn't look good

I think all comments above have been addressed now. The stringent checks on the inputs have mostly been removed, letting inputs reach UFL in most cases. Some checks remain inside _derive_block_jacobian (see comment), to prevent from breaking the code that here calculates the component-wise Jacobian.

Could you please have another look at it when you have time, and let me know if there are still any concerns?

Could you link the issue so it auto closes/links to the PR?

Could you link the issue so it auto closes/links to the PR?

done now

Can you fix up the linting issues caught in the CI?

Can you fix up the linting issues caught in the CI?

Thanks for bringing it up. I've amended it and it's now passing those checks.

I've also verified that sphinx will generate the documentation nicely from derivative_block's docstring. I did some extra checks adding it to a temporary local documentation build and noticed issues with code hyperlinks (they weren't working with the {py:fun} syntax, and switched to :func:).

There seem to be still ruff checks failing. Ensure you have the latest version installed when running the checks.