Proposed resolution:

This wording is relative to N5054.

1. Modify [exec.run.loop.types] as indicated:

   -4- Let sch be an expression of type run-loop-scheduler. The expression schedule(sch) has type run-loopsender and is not potentially-throwing if sch is not potentially-throwing.

   -5- For type set-tag other than `set_error_t`, the expression get_completion_scheduler<set-tag>(get_env(schedule(sch))) == sch evaluates to `true`.

   -?- The expression get_forward_progress_guarantee(sch) has the value `forward_progress_guarantee::parallel`.

   class run-loop-sender;

   -6- run-loop-sender is an exposition-only type that satisfies `sender`. […]

2. Modify [exec.run.loop.types] as indicated:

   -1- `inline_scheduler` is a class that models `scheduler` ([exec.sched]). All objects of type `inline_scheduler` are equal. For a subexpression `sch` of type `inline_scheduler`, a query object `q` with type other than cv `get_forward_progress_guarantee_t`, and a pack of subexpressions `args`, the expression `sch.query(q, args...)` is expression-equivalent to inline-attrs<set_value_t>().query(q, args...).

   -?- For a subexpression `sch` of type `inline_scheduler`, the expression `get_forward_progress_guarantee(sch)` has the value `forward_progress_guarantee::weakly_parallel`.

The resolution of LWG 4354 removed the default of `get_forward_progress_guarantee` (`forward_progress_guarantee::weakly_parallel`) from [exec.get.fwd.progress] and added `get_forward_progress_guarantee(sch)` to the requirements of the scheduler concept in [exec.sched]. It did not add the query to the standard schedulers that relied on the default:

• [exec.run.loop.types] p1 says that run-loop-scheduler "is an unspecified type that models scheduler", but the value of `get_forward_progress_guarantee` for it is not specified.

• [exec.inline.scheduler] p1 says that `inline_scheduler` "is a class that models scheduler", but also that `sch.query(q, args...)` is expression-equivalent to inline-attrs<set_value_t>().query(q, args...), and inline-attrs ([exec.snd.expos]) answers only `get_completion_scheduler` and `get_completion_domain`. So `get_forward_progress_guarantee(inline_scheduler())` is ill-formed, and `inline_scheduler` does not satisfy `scheduler`.

`parallel_scheduler` ([exec.par.scheduler]) and `task_scheduler` ([exec.task.scheduler]) already specify the query.

For run-loop-scheduler, scheduled work runs one item after another on the thread that calls `run()`, and an item that has started continues to make progress, so the scheduler can provide parallel forward progress, as observed in the discussion of LWG 4354.

For `inline_scheduler`, work runs on whichever execution agent starts the operation, so it cannot promise more than `weakly_parallel`, which is also the value it had before LWG 4354.

Implementation experience: stdexec, reports `forward_progress_guarantee::parallel` for the scheduler of its `run_loop` and `forward_progress_guarantee::weakly_parallel` for its `inline_scheduler`.