diff --git a/minutes/2026-10-06.md b/minutes/2026-10-06.md
new file mode 100644
index 0000000..1dfacdd
--- /dev/null
+++ b/minutes/2026-10-06.md
@@ -0,0 +1,576 @@
+# Libs Meeting 2026-10-06
+
+###### tags: `Libs Meetings` `Minutes`
+
+**Meeting Link**: https://meet.jit.si/the-libs-agenda
+**Attendees**: Fon, The 8472, Amanieu, Josh Triplett, Nurzhan, Asder, Chris Denton, thomcc, Josh Stone, James Muriuki
+
+## Agenda
+
+- Nominated items
+- Regressions
+- FCPs (optional)
+- ACPs (optional)
+- Anything else?
+
+
+## Triage
+
+
+### Backports
+
+#### [rust.tf/163809](https://rust.tf/163809) Switch TLS implementation for wasi and bump SDK version to 34
+
+Fon: This came up because in thread local storage destructors aren't being run on 1.99. This is a tier-2 target. There was an issue with the PR because it does an SDK bump. I'll let the wazi people figure this out, ??
+
+(Crickets.)
+
+Fon: 4 people said this doesn't justify a release on its own. Trevor changed his mind after. I guess we'll say yes on that one.
+
+#### [rust.tf/163342](https://rust.tf/163342) Don't imply incorrect things about `Global` in the docs of `System`
+
+Fon: I've been marking all allocator changes for beta backport just because there's no harm to merge with regular backports.
+
+### Prioritization Requested
+
+#### [rust.tf/163748](https://rust.tf/163748) Regression 1.98 → 1.99: `thread_local!` destructors no longer run at thread exit on `wasm32-wasip1-threads`
+
+Fon: This is the first backport.
+
+(Detour to discuss the agenda format and generator.)
+
+#### [rust.tf/163820](https://rust.tf/163820) 1.100\-beta regression: `bool::toggle` collides with extension method of the same name but different signature
+
+Fon: This is the expected breakage from adding a new method. They had a mutable version that returned a boolean, and ours doesn't. It fails on beta. I'm inclined to say "sorry" because it's going to be in a release with a FCW, and it's just one crate.
+
+Josh: It's notable that it's not just one crate that does this but one crate that does this with a signature that the std does. Lots of people do this, and then they will suddenly find themselves using ours instead of theirs.
+
+Fon: (Reasoning for why std's doesn't return.)
+
+Josh: I think we're doing the correct thing. I think we should treat this as allowed breakage. Would our trait evolution efforts help us not make this breakage in the future? I think no because it's a conflict between inherent and trait.
+
+??
+
+Fon: I'll just comment and close the issue.
+
+#### [rust.tf/163822](https://rust.tf/163822) 1.100\-beta regression: `Code` is ambiguous
+
+Fon: This is upsetting. This is the one using a glob import. We change this from a struct to an opaque extern type. Because the person did a glob import on the type itself, it now fails. I don't think we have an explicit rule on this, but people said that glob imports on std things are bad, and this feels like an extension of that. I think we should tell this person "please don't do this again, ever". The larger question is whether we want a compiler lint for that.
+
+The 8472: There's no link to the code?
+
+Fon: I meant the code that they're doing is included in the diagnostic. Code is now referring to the assoc type and also something else that they imported.
+
+Josh: Broadly +1 for "you should not use glob with std types except for preludes". But I'm wondering if we should encourage the shipping of a rustc lint to that effect, like a warn-by-default against ...
+
+The 8472: The discussion in the issue is pretty much that.
+
+??
+
+Fon: I tihnk we could extend that to allow a ?? wildcard imports from non-preludes.
+
+Josh: I'm suggesting a lint for "you're importing the std via a wildcard".
+
+Fon: The vibe is we're going to keep this open to look at lint options, but this is broken.
+
+#### [rust.tf/163837](https://rust.tf/163837) 1.100\-beta regression: expected `Global`, found type parameter `A`
+
+Fon: This is related to Allocator. This person's getting around the instability of the A parameter by using an underscore for it. I think we're ??. It feels like another acceptable breakage kind of deal.
+
+Josh: I'd go further and say this whole thing appears to be a pile of interesting polyfills for std bits that's ??. On this basis, I think this is not only allowed but also unsurpising breakage. I think it's in the TIHI category.
+
+### Nominated
+
+#### [rust.tf/135806](https://rust.tf/135806) Tracking Issue for `#![feature(phantom_variance_markers)]`
+
+Fon: This is on the phantom variance marker types. The issue is that there are impld as opaque wrappers over PhantomData. That's bad usability-wise. There's a suggestion to use a type alias, which is kind of weird, also the option of ?? items, and a compiler feature to make defaulted fields work on unstable before they're fully stable. ??
+
+Amanieu: I actually implemented (via an LLM) a magic attribute that turns these types into compiler magic, like PhantomData. It works but the diff is big. The main issue is that there's a lot of special casing around PhantomData, particularly around lints that ignore PD's fields.
+
+Fon: ?? another issue with PhantonPinned ??
+
+Amanieu: You still need a special attr to give them ?? because they would become unit structs ??
+
+Amanieu: Back to the options we have, we could go forward with the special compiler support, or keep what we have today, or turn these into type aliases for PhantomData (mostly works and they get compiler support for free -- but you lose the ability to instantiate these by name).
+
+Jacob: That's the concern that I had. Otherwise I'd be OK with type alises. And the diagnostic for that is suboptimal now.
+
+Fon: Anything short of the type alias option or leaving it alone would require lang intervention. We'd need to bother lang anyway if we need to add more lints.
+
+Josh: Vague +1 on the vibe of lang being on board. Might bikeshed this extensively, just as we would, but broadly speaking a lang solution makes sense.
+
+Jacob: I'm fine with that. If we can find a way to construct the types without using braces, then it's a go from me.
+
+Fon: I believe the end result would be that these are genuinely unit structs, just through compiler magic. I think either way we're going to continue with Amanieu's attribute approach and come back here if it doesn't work.
+
+#### [rust.tf/163818](https://rust.tf/163818) remove\_dir\_all: avoid deleting symlinks to files on Unix
+
+Fon: This is an ask from Ralf. The idea is that rmdir all shouldn't delete any symlinks. rmdir -p, I think, doesn't do that.
+
+Josh: Which symlinks would this not remove? I'm expecting ??
+
+The 8472: The current logic is if you pointed to a path that's a symlink, then it removes that and doesn't descend into it.
+
+Josh: So it's "don't follow the symlink and remove through it"?
+
+The 8472: No, we already don't do that. ?? Ralf's PR proposes checking if the target behind the SL is a regular file or directory.
+
+Josh: Why?
+
+The 8472: Consistency with Windows and ??.
+
+Josh: Can we fix Windows to stop doing that?
+
+??
+
+Fon:
+
+The 8472: But there's a special case that if it's a symlink, it also deletes it for some reason. I posted a comment with a summary of the various recursive options do. The general strategies are, it must be a directory or it just deletes anything with the exception that it still doesn't follow symlinks. All other languages do this except ours.
+
+Josh: Seems like anything we do here that's racy seems suboptimal, like checking the target. I don't know why we decided on an API like that. Seems like an API we could implement more simply and that's not racy is "you pointed me at a thing, an I'll make it go away". I think we should have it whether or not it's this operation or not. If we don't delete ??
+
+The 8472: Yes, either delete whatever you find or require it to be a directory, fail otherwise. The middle ground we have now is strange.
+
+Josh: Worth noting that either change would be a breaking change to behavior. The change in the direction of ?? 
+
+The 8472: This is actually documented (2nd line of the docs).
+
+Fon: The reason for the weird behavior is that on Windows the remove functions require you to specify whether it's a directory or file. I do think it's a mistake to mirror that on Linux because it's racy. I think that going for the most consistent API is probably best.
+
+Josh: 3 options: 1) modify this to never remove symlinks; 2) document this as being consistent with always removing symlinks; 3) transition to deleting a file if you point to it. All 3 are defensible. "Delete a symlink but only based on what it's pointing to" is not one of the options.
+
+Chris: I'd be concerned about breaking changes to behavior.
+
+Josh: Also the current behavior will be breaking to somebody who didn't read the docs.
+
+The 8472: I looked at cap-std and they're replicating what std does.
+
+Josh: Our easiest option is to keep the current behavior and document it more clearly.
+
+Fon: Ralf says in the issue that the case he's trying to improbe is tested on Windows specifically. ??
+
+Chris: I don't think we should design APIs based on getting a test to pass. It should be the other way around.
+
+Josh: Chris, is there something fundamental about Windows ?? that would make it difficult to implement ?? consistent with Unix?
+
+??
+
+Fon: The concept of symlinks isn't universal.
+
+??
+
+Josh: Do we currently remove junctions if you do remove dir all but don't follow them?
+
+Chris: Yes.
+
+Fon: To provide a response, do we want to say that the better option is to propose new APIs rather than changing the existing one?
+
+Josh: Possibly. We could say that API could be intended to become the new remove_dir_all over an edition.
+
+??: The edition redirect feature is being worked on.
+
+The 8472: I tihnk that removing the symlink special case and refusing to delete the thing may be possible ??
+
+Josh: Crater ??
+
+Josh: Based off what Chris said that we can't do the Windows behavior on Unix and vice versa without a race, I'd sat that the option to document the current behavior is the easiest. ??
+
+Fon: Happy to summarize it for Ralf.
+
+Josh: I'd be happy to do that too.
+
+Fon: Also we don't probably want to close this immediately.  I tihnk we should ask Ralf for more motivation.
+
+The 8472: I suspect he's trying to make Miri more portable.
+
+Fon: The main issue is that symlinks aren't portable.
+
+#### [rust.tf/141975](https://rust.tf/141975) Tracking Issue for `unix_send_signal`
+
+Fon: I thought this issue would be harder than the previous one because signals break everything.
+
+Josh: The 2 open questions: 1) Should it take self or &mut self; why is our existing kill/wait operation taking a &mut. Since signal doesn't track any state and doesn't need to write into the object, I'd propose that we shouldn't. Someone can already ask for the OS ID and then send a signal. ?? So I think it should be &self and not &mut self.
+
+Amanieu: Agreed, but the kill must happen before the wait because wait releases the PID for reuse. And taking &mut self is the synchronization we need, so we don't need that for the kill.
+
+The 8472: With ?? ID you can wait on it.
+
+Josh: I'd argue it's not about ownership of the PID and it's just that wait needs to write the status into the child.
+
+Amanieu: I think it is about that because once you've aited on it, you no longer own the PID.
+
+Josh: Is there agreement that send_singal doesn't have ownership considerations here?
+
+??
+
+Josh: I'll summarize the 1st in the issue. 2) What is the form of a sgnal and how should we provide that? One option is that signals are integers and then we provide some constants for some of these... The other is that we have a newtype that makes this more type safe and had from_raw to_raw, and constants for common portable cases. Pros: more rusty, cons: less consistent with the rest of std. We could start doing that and eventually may add typesafe UID, GIDs etc. Or we could make it consistent to the existing types and say we might do wrappers later.
+
+Josh: Another caveat is that there are APIs where the sign of the number you're passing around has significance ??
+
+Fon: Newtype sounds reasonable for a portable API. We'd have one signal for kill, and it'd be equivalent to calling the kill method.
+
+Josh: I meant portable to Unix systems, not portable to Windows, etc.
+
+Fon: I mention portable because we do this pattern with permissions where we have a permissions type for files, and then the permissions has an extension where you can access it as a u32 on Unix. I don't think we ??
+
+The 8472: 2 things: 1) we cannot change kill because the windows impl uses &mut to call ?? under some conditions.
+
+Chris: We can change that.
+
+The 8472: It does it for error handking, so I'm not sure we can. 2) I don't think UID is a good example vecause they don't have much meaning. Permissions are a better example ??
+
+Josh: There's not a complex encoding here. The rationale for the newtype is to avoid mixing the different IDs up. If we didn't already have UID and GID I'd say that a repr(transparent) wrapper around this is the way to go.
+
+Fon: ?? SIGRT ?? and we can't map that into an enum unless we add ?? to how enums work. I agree with the portability issue. I don't think that newtype is going to help over constants. I don't think signs are used for signal ID. I'd say just make it a u32 but that'd break libc.
+
+thomcc: I was the one who suggested doing a newtype. I think hiding it might be worth it because people might think this isn't something that changes, and that the signal concepts are the same across systems. ?? The actual values are system-specific.
+
+Josh: If we decide to make them free constants, I'd put them in a module. I like the idea of having them be associated consts.
+
+thomcc: I still think it's cleaner to do it as a repr(transparent) struct. The downside is that we do have a function that returns a signal and returns a `?32`.
+
+Josh: We could fix that.
+
+??
+
+Josh: The other downside to then newtype is bikeshedding the constants before we can ship this.
+
+The 8472: Doesn't sound too bad.
+
+thomcc: Doesn't sound like there's much contention around that.
+
+??
+
+Fon: I think there are some cases where the abbrev means different things on different platforms.
+
+Josh: That'd be useful, I don't think we should expand SIGFPE to Signal::FLOATING_POINT_EXCEPTION.
+
+Amanieu(chat): I'm against an opaque type: if you're manually sending signals then you want the low level control to be able to send any signal number. 
+
+The 8472(chat): "opaque" really just means wrapper, you can still pass in any number as needed 
+
+Fon: I guess we're lukewarm in favor of the transparent opaque newtype. And making consts for singals, I'm loosely in favor of making KILL be the only one offered by default because that's the only thing you can do with a child involving a signal.
+
+??
+
+Josh: I realized something that might sidestep the bikeshed. Could we just do both canonical and historical names? Like both `INT` and `INTERRUPT`?
+
+Josh S: Are there other cases where we do both instead of just a doc alias?
+
+Fon: I have a feeling that we still need to figure out how to expose a set of signals. Can we agree that it should be a C int instead of i32 for C compat?
+
+Josh(later): I confirmed that there are no targets supported by Rust where signals aren't i32.
+
+Josh: I agree.
+
+Fon: I think ??
+
+The 8472: Do people even need terminate or interrupt (the names)?
+
+Josh: I'd argue for just naming these exactly what the underlying signal is, except those that were gratuitously abbreviated, and I feel like it couldn't hurt to provide both.
+
+Fon: I think we can deal with the bikeshed later.
+
+Josh: Are we leaning towards "take an int and provide constants"?
+
+Fon: Constants are going to be hard to figure out, and whether they're newtyped or not doesn't affect the implementation difficulty. We could decide later.
+
+#### [rust.tf/libs864](https://rust.tf/libs864) Extra tracking labels for libs team
+
+#### [rust.tf/libs897](https://rust.tf/libs897) Moving libs policies to Forge
+
+
+### Regressions
+
+#### [rust.tf/163614](https://rust.tf/163614) `P-high` Regression in Rust 1.99: missing symbol `wcslen`
+
+Fon: Essentially, it's UEFI ?? specifically?
+
+Josh S: It was anything that doesn't have this synbol ??.
+
+Fon: So it affects more than one target, it's just that UEFI was a good example.
+
+Josh T: Our build of std on UEFI is funky in other ways too.
+
+Josh S: There's a workaround...
+
+Fon: If this is causing compiler errors, how did we release it?
+
+Josh S: Becasue we don't link anything for this target.
+
+Josh T: Could we always build the library for these targets with this option?
+
+??
+
+Josh T, Fon: I'm fine with that.
+
+Fon: There's nothing linked in this issue that talks about both kinds of changes. Might be worth including in the issue. I'm also confused about how we build it because I believe we run tests on UEFI.
+
+The 8472: 
+
+Fon: AFAIK, tier-2 targets run tests but they're allowed to skip tests.
+
+Josh T: Do we need to do anything here other than approve the backport?
+
+Fon: There is a ?? make script to test that we can make cargo, but I guess it doesn't include this. ?? I wonder what the test is that's running on UEFI. There is one that runs a basic program.
+
+Josh S: I think a smoke test would have caught it, even something that was just an empty main.
+
+The 8472: It's surprising that this didn't catch it: https://github.com/rust-lang/rust/blob/main/tests/run-make-cargo/uefi-qemu/uefi_qemu_test/src/main.rs
+
+Fon: I think that every target where we support std should have an empty main that compiles ??
+
+Josh S: ?? wcs len ??
+
+Fon: Do we actually need to approve this backport if this is a compiler builtins change?
+
+Josh S: The place where the compiler builtins fixed this was a subtree update ??
+
+??
+
+Fon: If the libs team can do anything, we will, but right now we don't have anything on this issue.
+
+Josh S: If we did a pseudo-PR or approval in this meeting, is there anyone who objects to doing a backport?
+
+Josh S: I'll probably be running the release side of this one, so I can ping libs-ping or something.
+
+Fon: If you add the t-libs label to it, it'll show up in the backports channel.
+
+??
+
+Josh S: I'll do something on that PR ?? and will stable nominate that.
+
+Fon: There's not much process we can add to this other than saying, go for it.
+
+Josh S: https://github.com/rust-lang/rust/pull/162816 went through beta nomination. We picked a couple of commits from that. That beta is now stable. We want to pick an additional commit out of that. So I will stable nominate this PR with the comment that we're looking at a different commit.
+
+Fon: That's fine.
+
+#### [rust.tf/139730](https://rust.tf/139730) `P-high` A case of compound x86\_64 performance regression caused by LLVM 20 and #124810
+
+(Meta note from Josh: some of these might not actually be p-high.)
+
+Fon: This feels like a compiler regression and not a libs one. We can remove the t-libs tag and that'll remove it from our agenda. I'll look at these and decide what we want to do.
+
+Fon: Note, agenda generator date these were opened
+
+Fon: The long-term solution is to assign priority correctly.
+
+#### [rust.tf/124216](https://rust.tf/124216) `P-medium` Performance regression: rustc failed to optimize specific x86\-64 SIMD intrinsics after 1.75.0
+
+#### [rust.tf/130320](https://rust.tf/130320) `P-medium` stdlib code size increase in nightly\-2024\-09\-01 for aarch64\-linux\-android
+
+#### [rust.tf/142119](https://rust.tf/142119) `P-medium` Linking a Rust staticlib unexpectedly changes C math functions from libm to bundled ones from compiler\-builtins
+
+#### [rust.tf/149752](https://rust.tf/149752) `P-high` TrivialClone is not derived for generic types (Performance regression)
+
+#### [rust.tf/153425](https://rust.tf/153425) `P-medium` `&pin!()` stopped being deref\-coerced in rust 1.88
+
+
+## FCPs
+
+#### [rust.tf/162444](https://rust.tf/162444#issuecomment-5585540374) Make `std::fs::{File, ReadDir, DirEntry}` always `needs_drop` even when unsupported.
+- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 1 libs-former-fcp: [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+
+#### [rust.tf/161531](https://rust.tf/161531#issuecomment-5381271798) Remove `T: Send + Sync` bound from `Arc::downcast`
+- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 1 libs-former-fcp: [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+
+#### [rust.tf/121641](https://rust.tf/121641#issuecomment-3821243226) Tracking Issue for `OnceCell/Lock::get_mut_or_init`
+- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 1 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu)
+
+#### [rust.tf/162012](https://rust.tf/162012#issuecomment-5470063322) unseal std::io::IsTerminal
+- needs 1 libs: [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+
+#### [rust.tf/163499](https://rust.tf/163499#issuecomment-5895502691) vec: stabilise allocators for into\_iter
+- needs 4 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc)
+
+#### [rust.tf/163458](https://rust.tf/163458#issuecomment-5933589602) stabilize {Rc, Arc}::is\_unique
+- needs 4 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc)
+
+#### [rust.tf/117222](https://rust.tf/117222#issuecomment-5650063839) Tracking Issue for NEON FCMA intrinsics
+- needs 3 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 1 libs-former-fcp: [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+
+#### [rust.tf/161908](https://rust.tf/161908#issuecomment-5453467135) Stabilize `ExitCode::exit_process`
+- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+
+#### [rust.tf/163816](https://rust.tf/163816#issuecomment-5998492761) stabilize String::into\_chars
+- needs 5 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@Mark-Simulacrum](https://rfcbot.rs/fcp/Mark-Simulacrum) [@nia-e](https://rfcbot.rs/fcp/nia-e) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc)
+
+#### [rust.tf/151973](https://rust.tf/151973#issuecomment-5413059244) Stabilize `proc_macro_value` feature
+- needs 4 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@dtolnay](https://rfcbot.rs/fcp/dtolnay) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 1 libs-former-fcp: [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+
+#### [rust.tf/163753](https://rust.tf/163753#issuecomment-5979888082) implement PartialEq\<VecDeque\<U\>\> for Vec\<T\>, &\[T\], &mut \[T\], \[T; N\], &\[T; N\] and &mut \[T; N\]
+- needs 7 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@Mark-Simulacrum](https://rfcbot.rs/fcp/Mark-Simulacrum) [@cuviper](https://rfcbot.rs/fcp/cuviper) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@nia-e](https://rfcbot.rs/fcp/nia-e) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc)
+
+#### [rust.tf/80437](https://rust.tf/80437#issuecomment-1125982498) Tracking Issue for `box_into_inner`
+- needs 1 libs: [@dtolnay](https://rfcbot.rs/fcp/dtolnay)
+- blocked by concern: [convey the use case in documentation](https://rust.tf/80437#issuecomment-1150255531)
+
+#### [rust.tf/158368](https://rust.tf/158368#issuecomment-4845707778) std: make `Instant` a signed `Duration` on all platforms
+- needs 2 libs: [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc)
+- blocked by concern: [input-from-andrew-gallant](https://rust.tf/158368#issuecomment-5320384629)
+
+#### [rust.tf/126840](https://rust.tf/126840#issuecomment-4860808228) Tracking Issue for `mpmc`
+- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- blocked by concern: [async-and-unbounded-are-not-the-same-thing](https://rust.tf/126840#issuecomment-5181310113)
+
+#### [rust.tf/163067](https://rust.tf/163067#issuecomment-5749755058) Stabilize `std::os::unix::process::CommandExt::chroot` (`process_chroot`)
+- needs 2 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@the8472](https://rfcbot.rs/fcp/the8472)
+- blocked by concern: [tests, examples and improved documentation](https://rust.tf/163067#issuecomment-5783213629)
+
+#### [rust.tf/153261](https://rust.tf/153261#issuecomment-4164136648) Partially stabilize `ptr_alignment_type` as `alignment_type`
+- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- blocked by concern: [non_zero_name_consistency](https://rust.tf/153261#issuecomment-4608729444)
+
+#### [rust.tf/134915](https://rust.tf/134915#issuecomment-4971877356) Tracking Issue for ByteStr/ByteString
+- needs 1 libs: [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 1 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu)
+- blocked by concern: [deref-vs-methods](https://rust.tf/134915#issuecomment-4971877039)
+
+#### [rust.tf/109737](https://rust.tf/109737#issuecomment-3821238426) Tracking Issue for `once_cell_try`
+- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 1 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu)
+- blocked by concern: [try-trait](https://rust.tf/109737#issuecomment-3869682069)
+
+#### [rust.tf/161947](https://rust.tf/161947#issuecomment-5470072560) std::io: impl IsTerminal for {Empty, Repeat, Sink, Take}
+- needs 1 libs: [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+- blocked by concern: [always-false](https://rust.tf/161947#issuecomment-5496414873)
+
+#### [rust.tf/163328](https://rust.tf/163328#issuecomment-5833061292) Stabilize `iter_advance_by`
+- needs 4 libs: [@Mark-Simulacrum](https://rfcbot.rs/fcp/Mark-Simulacrum) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc)
+- blocked by concern: [nth-advance-by](https://rust.tf/163328#issuecomment-5880235659)
+
+#### [rust.tf/160951](https://rust.tf/160951#issuecomment-5365520096) Stabilize `core::io::{Error(Kind), IoSlice(Mut), Result}`
+- needs 3 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472)
+- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi)
+- blocked by concern: [solicit-feedback](https://rust.tf/160951#issuecomment-5458232285)
+
+#### [rust.tf/141994](https://rust.tf/141994#issuecomment-3368366135) add Iterator::contains
+- has all checkboxes
+- blocked by concern: [shadowing](https://rust.tf/141994#issuecomment-3469674757)
+
+#### [rust.tf/160394](https://rust.tf/160394#issuecomment-5188875192) Lang/libs coordination question: okay for libs to stabilize traits with `final fn` in them?
+- needs 1 lang: [@nikomatsakis](https://rfcbot.rs/fcp/nikomatsakis)
+- needs 2 types: [@lcnr](https://rfcbot.rs/fcp/lcnr) [@spastorino](https://rfcbot.rs/fcp/spastorino)
+- blocked by concern: [types-semantics-and-documentation](https://rust.tf/160394#issuecomment-5780228455)
+
+#### [rust.tf/132484](https://rust.tf/132484#issuecomment-2472310685) unix: Relax escaping in `Debug` impl on `Command`
+- has all checkboxes
+- blocked by concern: [!](https://rust.tf/132484#issuecomment-2474536101)
+- blocked by concern: [use-single-quotes](https://rust.tf/132484#issuecomment-2474536101)
+
+#### [rust.tf/106418](https://rust.tf/106418#issuecomment-1954725313) Implement `PartialOrd` and `Ord` for `Discriminant`
+- needs 2 lang: [@nikomatsakis](https://rfcbot.rs/fcp/nikomatsakis) [@scottmcm](https://rfcbot.rs/fcp/scottmcm)
+- blocked by concern: [overly-broad](https://rust.tf/106418#issuecomment-1994833151)
+- blocked by concern: [rfc-3607-instead](https://rust.tf/106418#issuecomment-2271666365)
+
+#### [rust.tf/157168](https://rust.tf/157168#issuecomment-4781605913) Stabilize `Rng` and `SystemRng`
+- needs 2 libs: [@dtolnay](https://rfcbot.rs/fcp/dtolnay) [@the8472](https://rfcbot.rs/fcp/the8472)
+- blocked by concern: [unavailable SystemRng](https://rust.tf/157168#issuecomment-4781604491)
+- blocked by concern: [global](https://rust.tf/157168#issuecomment-4808937889)
+- blocked by concern: [fallibility](https://rust.tf/157168#issuecomment-4876547147)
+
+
+## ACPs
+
+#### Meta
+
+Amanieu: We haven't approved any ACPs in at least a month.
+
+Fon: This is coming up with the async ACP changes. We've also said, let's not use the MCP automation from the compiler team. Maybe we want to change our mind about enabling that.
+
+The 8472: I'm seeing that at least Josh seconded one.
+
+Fon: We have seconds active on things.
+
+The 8472: Having a bot for the timer would be good.
+
+Fon: Concerns are separate from the MCP, AFAIK. But those need to be done on GitHub. ??
+
+The 8472: IIRC, the disagreement was about telling people not to discuss and go to Zulip for that.
+
+Fon: I think just changing that to be a string config in triagebot about ?? and making a compiler-team PR to keep their current template would work fine for that (??).
+
+#### [rust.tf/libs868](https://rust.tf/libs868) Add API to call codeview_annotation intrinsic
+
+Chris: We don't have anything in core like OS Windows or ??
+
+Fon: I don't feel against that but I guess that's a hot take because the ship has sailed on putting os-specific things in core. The main issue is that now we're adding the os module in core, which maybe people are against. I'd be against putting a windows-specific attribute in core::hint.
+
+??
+
+The 8472: Since the other platforms have to use for it, it would make sense to put it in a Windows module and have it available without a cfg.
+
+??
+
+Josh: Unless you're using this is code specific to windows, you're going to be wrapping it in a cfg attr. Broadly, if we don't make this a hint that innately has a noop wrapper elsewhere, then people will add the noop wrapper. I also get the impression that this is already going to be wrapped in the ecosystem by some complicated set of macros. ?? Should it be in core or ...?
+
+Fon: It should be in core because it's purely compile-time information.
+
+Josh: ?? ship it, let the ecosystem wrap it. If there are common wrappers in the ecosystem we can adopt, we can upstream those later.
+
+??
+
+The 8472: Is this for only for target ?? modules or is this useful in other places?
+
+Fon: Because Windows isn't a monokernel like Linux, a lot of the drivers are user space code. ?? 
+
+??
+
+Chris: This can be used for anything where you have a PDB.
+
+??
+
+Fon: The comment here is put it in os::windows in core for now. This is the 1st occasion of the os module in core. ?? The windows module shouldn't be accessible outside of Windows.
+
+Chris: I can comment.
+
+### New
+
+#### [rust.tf/libs904](https://rust.tf/libs904) ACP : Add a fallible but always safe method to compute layout from `Metadata`
+
+#### [rust.tf/libs902](https://rust.tf/libs902) Add portable OpenOptions flag to not follow symlinks
+
+#### [rust.tf/libs900](https://rust.tf/libs900) Thread spawn hooks for thread::Builder
+
+#### [rust.tf/libs899](https://rust.tf/libs899) ACP: StartBounds and EndBounds
+
+#### [rust.tf/libs898](https://rust.tf/libs898) Introduce `UnixSeqListener`/`UnixSeqPacket`
+
+#### [rust.tf/libs896](https://rust.tf/libs896) Add a `get_disjoint_mut` method to `BTreeMap`
+
+#### [rust.tf/libs895](https://rust.tf/libs895) Add `Result::is_ok_or` and `Result::is_err_or`
+
+#### [rust.tf/libs892](https://rust.tf/libs892) API for better handling of FFI span
+
+#### [rust.tf/libs890](https://rust.tf/libs890) Add `core::mem::replace_with`
+
+#### [rust.tf/libs889](https://rust.tf/libs889) Support `MiB` and `M` suffix in `RUST_MIN_STACK`
+
+
+### Stalled
+
+#### [rust.tf/libs821](https://rust.tf/libs821) ACP: `impl From<&Rc<T>> for Rc<T>`
+
+#### [rust.tf/libs828](https://rust.tf/libs828) Separate `Components` iterator implementation into non\-prefixed & prefixed versions
+
+#### [rust.tf/libs819](https://rust.tf/libs819) ACP: Remove 'static from Any itself, moving the bound to the operations themselves
+
+#### [rust.tf/libs827](https://rust.tf/libs827) ACP: add `unsafe trait PureRef<U>` to guarantee purity of the AsRef/Deref/Borrow traits
+
+#### [rust.tf/libs826](https://rust.tf/libs826) Add `core::mem::size_of_field!`
+
+#### [rust.tf/libs832](https://rust.tf/libs832) Type\-smart `intersect` on ranges \-\- v2
+
+#### [rust.tf/libs835](https://rust.tf/libs835) Rename `VecDeque::truncate` to greatly reduce ambiguity
+
+
+_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_