Address comments

text/3319-aligned-trait.md

@@ -37,6 +37,8 @@ Relaxing `Self: Sized` bounds to `Self: Aligned` allows implementing those metho
 
 - `core::mem::align_of<T>()` for slices could be implemented with a library. However, a library would be unable to support records that contain a slice as the last field. Also, relaxing the trait dyn safety requirements can only be done with a language feature.
 - `?Aligned` could be accepted as new syntax, equivalent to `?Sized`. However, I don't think it's worth it to have two ways to spell the exact same concept in the same edition.
+- There may be a use-case for types that are `Sized` but not `Aligned`. However, I don't know of such, and allowing it would likely cause backward-compatibility issues.
+- Traits with methods bounded by `where Self: Aligned` could be made fully object unsafe, instead of making it impossible just to call that specific method from a trait object. However, this would make the language strictly less useful, without gaining any simplicity (as `Sized` would remain special-cased).
 
 # Prior art
 
@@ -54,3 +56,4 @@ None that I am aware of.
 - Certain `Self: Sized` bounds in the standard library could be relaxed to `Self: Aligned`. However, this might cause backward-compatibility issues.
   - [IRLO topic](https://internals.rust-lang.org/t/removing-self-sized-and-backward-compatibility/17456) on how the issues could be addressed.
 - [RFC 3308: `core::mem::offset_of`](https://github.com/rust-lang/rfcs/pull/3308) could, if accepted, be made to work on any `Aligned` type. One caveat is that if Rust ever gets structs with multiple unsized fields, those could be `Aligned` but not support `offset_of` for every field.
+- There has been discussion about adding other traits into the `Sized` hierarchy, like `DynSized`. If both `Aligned` and these other traits are integrated into Rust, their relative positions in the trait hierarchy will need to be determined.