text: Title: Reevaluating Experimental Functions for Streamlit Development
  Body: ### Checklist
  
  - [x] I have searched the [existing issues](https://github.com/streamlit/streamlit/issues) for similar feature requests.
  - [x] I added a descriptive title and summary to this issue.
  
  ### Summary
  
  Can someone please elaborate on the motivations behind the current approach to handle experimental functions in Streamlit?
  
  
  ### Why?
  
  By naming experimental functions as they would be called normally and marking them with warnings, it is still possible to maintain a clearer separation between stable and experimental features. This could streamline development, reduce documentation confusion, and minimize conceptual overlap.  This holds additional weight moving into AI augmented coding which appears to be here to stay.  I imagine many packages may be developed from the start with these paradigms in mind - such that they code semantically to promote consistency.
  
  Wouldn't naming experimental functions as they would be in their final form, but marking them with warnings indicating their experimental status (or a segregated import), help reduce confusion? This could make experimental functions easily identifiable and removable upon deprecation, preserving the core codebase's integrity while fostering innovation. Could this approach reduce cognitive load on developers, minimize documentation pollution, and improve overall development efficiency?  While this may sound nitpicky, I see large efficiencies to be gained by tailoring this towards new information ingestion and auto coding technologies - and just from an update standpoint.
  
  ### How?
  
  N/A
  
  ### Additional Context
  
  _No response_