According to the documentation, C-u org-todo is supposed to always force logging the state change and taking a logging note. That is true when the default logging behavior is to just log the state change, either because `org-log-repeat' is 'time, or because there is a "#+STARTUP: logrepeat" in-buffer setting. However, if that behavior is set specifically for an entry using the LOGGING=TODO(!), and the entry is a repeated task, you can't no longer force logging a note together with the state change using C-u org-todo. This can be seen with the following example:
* TODO Example SCHEDULED: <2026-09-29 Tue .+1d> :PROPERTIES: :LOGGING: TODO(!) :END: The agenda code is quite hard to follow but I think I figured it out why this happens. The way the note is setup is with the `org-add-log-setup' function. This functions sets some variables and then sets `org-store-log-note' as post-command hook. That function will setup the note when the command ends, according to the variables that `org-add-log-setup' set, and then remove itself from `post-command-hook'. For repeated tasks, org-todo is actually called twice when you invoke it, because the first call invokes itself again (via `org-auto-repeat-maybe'), but only the first one will have the C-u argument set. For the cases where everything works as expected, in the first call `org-add-log-setup' is called because of the universal argument, with the internal variables set accordingly, and in the second call it's not called. For the case where it doesn't work as expected, the first call is also done and the variables set correctly, but then in the second call `org-add-log-setup' is called again, and this time the internal variables are set according to the LOGGING property, overriding the previous values from the universal argument. As a result, only the time is logged but not a note. I'm not sure how it should be fixed, the code looks too spaguetti already and the fixes I can think of would only add up to that. If you don't have a problem with that I can submit a patch with the simplest fix I can think of, but I think this code would benefit from a refactor from someone who really understands it.
