it's unclear why this needs to be in the standard library when it can accomplished as a handler. as the first example I found: https://github.com/samber/slog-multi

I agree other third-party library like "slog-multi" accomplished this functionality. Although third-party solutions exist, standardizing this functionality offers several benefits:

• Consistency and Ease of Use: A standardized approach ensures consistent behavior and API across different projects using the slog package. This reduces the learning curve and simplifies adoption for new users.
• Discoverability and Integration: Integrating with a standard library feature is often easier. Users don't need to search for and manage dependencies on external packages, making development and maintenance smoother.
• Quality and Maintenance: Standard library features are actively maintained by the Go team, receiving regular updates, bug fixes, and security patches. This ensures a reliable and well-supported solution for users.

Using third-party library like "slog-multi" may not be maintained consistently, potentially leading to compatibility issues in the future.

CC @jba

@lxl-renren While I agree with you about the values of standardization, I don't think this particular feature warrants it. It is easy enough to write and not needed often enough to justify the added maintenance burden to the Go team.

However, that is just my opinion, and we can and should let the proposal process take its course.