I wouldn't want to do this, but I think I'd prefer something like:

import Component from '@glimmer/component'; 
import { on, or } from '@glimmer/template'; 
import { tracked } from '@starbeam/ember';

where,

@glimmer/template has:

This combines @glint/template, ember-truth-helpers

• the types from @glint/template
  • ModifierLike
  • HelperLike
  • ComponentLike
  • Invoke (currently private, but is the only way ember-resources is glint compatible 😅)
• eq
• notEq
• gte
• gt
• or
• and
• nor
• xor
• nand
• lt
• lte
• not
• get
• concat
• uniqueId
• page-title

and,

@starbeam/ember has:

this combines parts of @glimmer/tracking, tracked-built-ins, ember-resources, and ember-modifier (because with the right manage wiring, modifiers are resources)

• cell
• resource
• @tracked
• @cached
• ReactiveMap
• ReactiveSet
• ReactiveWeakMap
• ReactiveWeakSet

and these are

built in

and no longer (and many already didn't) need importing:

• on
• fn
• hash
• array
• hasBlock
• hasBlockParams
• helper (for currying)
• modifier (for currying)
• component (for currying)
• in-element
• log
• debugger

These should be deprecated / removed, imo

• action
• input
• link-to
• mount
• mut
• textarea
• unbound

Packages no longer needed (if all the above is done)

• @ember/modifier
• @ember/helper
• @glimmer/tracking
• @glint/template
• tracked-built-ins
• ember-resources
• ember-truth-helpers

Yea, I'm not a fan of the original proposal. I prefer clear import paths instead of importing everything from a single namespace to make it a little bit easier. With proper tooling support there shouldn't be a difference anyway.

I do think revisiting and streamlining the imports, as you suggest here, makes sense but that seems like a whole different discussion compared to what's suggested in the RFC? 😄

I can see how importing from the originating source package can be considered clearer, but it brings with it downside of introducing multiple concepts like Glimmer, Starbeam etc. Every-time you need to import something, there's the small mental tax of trying to remember which package it comes from.

I don't have a strong opinion on this, but from the point of view of someone new to Ember, I would think that importing common Ember constructs from an easy to remember place would simplify things greatly.

We can incrementally get there, at the most basic, we should reorganize the tools anyway.

Once we have vite by default, and can ensure that tree-shaking works, we could provide an import { on, fn, eq, tracked, etc } from '@ember/meta';

but I don't think it makes sense to strive for something like that unless we can make sure that unused functions are not shipped in folks apps.

but it brings with it downside of introducing multiple concepts like Glimmer, Starbeam etc

fwiw, all other frameworks have this split, so at the very least, we meet the status quo.

• nextjs has a ton of imports
• svelte has very few
• nuxt seems to all be globals
• remix has very few

Given the above suggestion, I think we'd have only 3 main concepts / imports for the whole framework (given that we align with all of Polaris' goals, as presented in the emberconf 2023 keynote)

• a component (a feature / refactoring boundary for a collection of "things")
• the reactive primitives and utilities (starbeam, works in JS and template)
• the template ulities (glimmer, needed pre-expression syntax (super handwave here, not anywhere near polaris timeline))

There are a lot of modules not mentioned, but I think if go hard on Polaris, we won't need most of our existing imports.