You’re asking for a procedural modeling workflow. It’s possible currently, but you’ll have to radically change your approach to modeling. Google / youtube for “Blender procedural modeling”.
And yeah, that’s not really a default, it’s the nature of polygonal/non-procedural modeling.
I believe what he is referring to is this going away after you create a primitive:
Maya can keep this data after the fact with History on. And a few other apps offer this as well. I don’t mean Houdini, like that. I just mean basic parametric modeling of primitives with history. Blender could improve on this by offering to allow parametric modeling to be non-destructive.
This is something else entirely:
Having parametric history is of course limited. But many people coming to Blender would expect it.
Currently, Blender’s Mesh (and BMesh) is just a soup of verts, edges, and faces. It would be very hard to retrofit some kind of “primitive” support as part of Meshes. One would somehow have to tag each geometry element with the primitive that it is part of. And then figure out what to do if someone subsequently edits (e.g., moves, deletes) one of those elements, or even harder, uses one of those elements for the basis of another operation (e.g., a bevel or inset).
There are three possible approaches that I can think of.
Keep keep track of the entire editing history, including the creation of primitives with parameters. Then be able to replay the editing history from any point, with the possibility to change the parameters of some primitives because the user has just edited those parameters. I guess this is probably what Maya does. I wonder how they get around the problem that the editing history could get enormous, and it would have to be saved in the .blend file. Also, what if the history no longer makes sense after you change a primitive? An example I can think of: what if you do a boolean operation that subtracts some part of the mesh. The part of the mesh that survives depends on the physical layout of vertices, so if you change a primitive parameter, different vertices and other other elements may survive. If a subsequent edit operation depended on a vertex that used to be there but no longer is after changing the primitive, what to do?
Use Modifiers. A primitive would be a modifier that generates geometry. To edit the mesh generated by the modifier afterwards, you’d need to add more modifiers – you couldn’t just use manual editing operations on them because you can’t even select the produced geometry in Edit mode. Sorcar and other Node-based geometry generating / transforming systems would be a more flexible way of doing this than modifiers, but is basically the same idea.
Introduce a new basic object type into Blender – like “Curve” is – that is separate from Mesh, and then try to make Meshes interact well with them – maybe regarding them as encapsulated meshes where you can attach to the vertices they expose but not much else. I think it would quickly get quite complicated if one tried to design such a system with the goal of having things like a subsequent inset of a face in a primitive to properly get fixed if the primitive parameters change.
I think the most likely scenario for getting what people want here will be option 2, though people probably really want option 1. I think option 1 would be a hard sell to current Blender developers, though I could be wrong. (However: just look at what a headache it already is to have a performant Undo – this could easily make it even harder to get there,)
P.S. the screenshot that Richard gave shows something that some users may be confused about: it seems like the primitives are parametric for a brief time, since that panel is there after the primitive is created and you can tweak its parameters and cause it to change – so why isn’t it easy for Blender to just persist that permanently? The answer is that this is just an illusion. The panel is actually a REDO panel: if you change something in there, it undoes the creation, and then redoes it with the new parameters. So it is not a parametric primitive, but rather a primitive that can be erased and redone as long as nothing has been done since then. To be able do this longer would get us into option 1 above, with the issues I mentioned there.
You know anywhere you can type you can use the number pad right?
Nothing’s hardcoded, it’s in the view tab of the viewport sidebar
This is exactly how Maya does it and is what is being asked for. The solution is not about creating a modeling history, as in some kind of unlimited node network which allows you to access various stages along the way and have that change propagate non-destructively like modifiers. You can do that with Maya using nodes. You would never do that using History. And one of the very fundamental things you learn about Maya is when and how to use History, what the limitations are. And mostly keep it turned off unless you really need it. But it comes in real handy when you know you can be working on blocking something out and want to come back to change the parametric settings of a primitive. That was what the poster was referring to. You don’t use it, for example if you are doing unlimited editing on something. But there are some edits that would stay. For example if you added some horizontal edge loops (and even scale them) you would know, logically you could still change the number of vertical sides. Start extruding, and go back, you will have a mess. Of course. And History is something you can turn on and off. Basically that is how it works in a nutshell. Anyway someone coming over from another package and seeing the illusion that is the parametric input will be confused. And frankly, it is just an annoying feature to have that thing just disappear on you. I have always hated this about Modeling in Blender. You do one little thing and poof! All your settings are gone. Not such a big deal for a simple primitive but all of the add mesh objects work this way. Start using one of those bolt makers or something more complex and you will be very very frustrated by this process.
Well, yes. What do you mean?
Yeah, if you could at least move, rotate and scale before losing the possibility to adjust them…
Defining size of a cube as a radius instead of three separate dimensions.
I use this addon for years but defaults should sort of work like the add on.
Basically every other 3D software does apart from Blender and that was my point.
Exactly. Extremely useful to be able to do at least that. Interactive positioning and so on for reference and I would say just general sanity…lol
And since we are on the thread of defaults who needs a bolt the size of King Kong by default?
You were acting like the number pad was useless because it has hotkeys mapped to it. But it functions as a normal number pad in any case you would need a number pad
Hahah, yeah. I needed some threads for a bulb today and used the addon to get them. I’m not sure why, but as soon as I added it I thought of this thread 
Obviously an M8 bolt means the bolt has a diameter of 8 meters - hence the M, right? Everybody knows that, lol.
Only in some countries of course!
M just means metric. Nominal diameter would be 8mm. I didn’t check if it was 8m, just that it was humongous. Who knows what the creator was thinking. Maybe there is a reason, like point accuracy with small numbers or something.
Yeah I know. I was just riffing with you.
You have a point about accuracy tough. Could be a factor.
Just that it would be nice to be able to scale it in Object Mode and keep those parameters intact.
Ah, I believe you have misread @Lumpengnom’s post, which states both the ability to use the number pad for navigation and fast numerical input as positive reasons for having a keyboard with a number pad.
Ah, yes, that seems to be the case.
Yup that does seem to be the case, Well… Now we are on the same page lol
