some editing to better reflect my concern

text/0000-const-generic-const-fn-bounds.md

@@ -467,6 +467,12 @@ This is strictly the least restrictive and generic variant, but is a semver
 hazard as changing a const fn's body to suddenly call a method that it did not before can break
 users of the function.
 
+# Unresolved questions
+
+* Is it possible to ensure that we are consistent about opt-in vs opt-out of
+  constness in static trait bounds, function pointers, and `dyn Trait` while
+  remaining backwards compatible? Also see [this discussion][dynamic_dispatch].
+
 # Future work
 
 This design is explicitly forward compatible to all future extensions the author could think
@@ -610,26 +616,40 @@ trait Foo {
 which does not force `impl const Foo for Type` to now require passing a `T` with an `impl const Bar`
 to the `a` method.
 
-## `const` function pointers
+## `const` function pointers and `dyn Trait`
+[dynamic_dispatch]: #const-function-pointers-and-dyn-trait
+
+The RFC discusses const bounds on *static* dispatch. What about *dynamic* dispatch?
+In Rust, that means function pointers and `dyn Trait`.
+
+### Function pointers
+
+This is illegal before and with this RFC:
 
 ```rust
 const fn foo(f: fn() -> i32) -> i32 {
     f()
 }
 ```
 
-is illegal before and with this RFC. While we can change the language to allow this feature, two
-questions make themselves known:
+To remain consistent with trait bounds as described in this RFC, it seems
+reasonable to assume that a `fn` pointer passed to a `const fn` would implicitly
+be required to point itself to a `const fn`, and to have an opt-out with
+`?const` for cases where `foo` does not actually want to call `f` (such as
+`RawWakerVTable::new`).
+
+However, there are two problems with this:
 
 1. fn pointers in constants
 
     ```rust
     const F: fn() -> i32 = ...;
     ```
 
-    is already legal in Rust today, even though the `F` doesn't need to be a `const` function.
-    Since we can't reuse this syntax, do we need a different syntax or should we just keep constants
-    as they are and just reuse the syntax in `const fn` arguments?
+    is already legal in Rust today, even though the `F` doesn't need to be a
+    `const` function.  Since we can't reuse this syntax, do we need a different
+    syntax or should the same syntax mean different things for `const` types and
+    `const fn` types?
 
 2. Opt out bounds might seem unintuitive?
 
@@ -661,26 +681,14 @@ fn foo(f: const fn() -> i32) -> i32 {
 }
 ```
 
-Which is useless except for ensuring some sense of "purity" of the function pointer ensuring that
+Which could be useful for ensuring some sense of "purity" of the function pointer ensuring that
 subsequent calls will only modify global state if passed in via arguments.
 
-## explicit `const` bounds
-[explicit_const]: #explicit-const
-
-`const` on the bounds (e.g. `T: const Trait`) requires an `impl const Trait` for any types used to
-replace `T`. This allows `const` trait bounds on any (even non-const) functions, e.g. in
-
-```rust
-fn foo<T: const Bar>() -> i32 {
-    const FOO: i32 = T::bar();
-    FOO
-}
-```
-
-Which, once `const` items and array lengths inside of functions can make use of the generics of
-the function, would allow the above function to actually exist.
+However, this would be inconsistent with what the RFC proposes for traits. That
+is particularly surprising when we consider that the exact same concern applies
+to `dyn Trait`.
 
-## `dyn Trait`
+### `dyn Trait`
 
 A natural extension to this RFC is to allow
 
@@ -698,6 +706,34 @@ const fn foo(bar: &dyn ?const Trait) -> SomeType {
 }
 ```
 
+However, the same concerns as for function pointers apply. In particular, this
+is already allowed on stable, without any check that the `Trait` implementation
+is `const`:
+
+```rust
+const F: &dyn Trait = ...;
+```
+
+Like with function pointers, we could instead make `dyn Trait` opt-in to
+constness with `dyn const Trait`, but that would be inconsistent with static
+trait bounds.
+
+## explicit `const` bounds
+[explicit_const]: #explicit-const-bounds
+
+`const` on the bounds (e.g. `T: const Trait`) requires an `impl const Trait` for any types used to
+replace `T`. This allows `const` trait bounds on any (even non-const) functions, e.g. in
+
+```rust
+fn foo<T: const Bar>() -> i32 {
+    const FOO: i32 = T::bar();
+    FOO
+}
+```
+
+Which, once `const` items and array lengths inside of functions can make use of the generics of
+the function, would allow the above function to actually exist.
+
 # Unresolved questions
 [unresolved-questions]: #unresolved-questions