These are additional inputs that would apply to the point 2.) in the first post - and which could be more generally called;
request for more node operations
2.) a) A color ramp (band / gradient) node
Procedurals are just a grayscale texture, we would need a node to colorize that texture (procedural or grayscale image texture). Of course you can mix two colors with a procedural, which can be further mixed with another color... but that's too limiting an cumbersome. The ideal solution is a color ramp (or colorband, or color gradient, it's all the same thing...), that colorizes the noise according to it's shade of gray. The colorband node should allow to add (and remove) an arbitrary number of breakpoints for each color we want to introduce, should allow setting an alpha value for the breakpoint that mixes the breakpoint color with grayscale original and possibly should have different interpolation types to choose from. The color band node can be also used to control contrast of an texture.
This feature has already been asked for, in
this and
this thread.
The picture below is taken from Blender. In it, the colorband feature is used to create a texture of metal rust points or similar phenomena, that can then be (mixed with the original metal texture and) applied to the specular parameter of a glossy material.
(
note: I'm using Blender to present visuals just because this is the only 3D package I own and use, not because I would like to force it's way of implementation)
2.) b) A Hue-Saturation-Value node
A HSV node would be very useful to control coloring tone of procedurals or imported images, without the need to create and import them from outside - say you import a diffuse texture for a metal material from outside, but create a specular texture (change tone, to have different reflections) from it inside Octane. You save importing one RGB image, which can be a lot.
A HSV node is also useful to desaturate a texture for use in single channel (grayscale) material parameters (eg. bump). This is automatically done in Octane if you connect a RGB tex to the input, but the transformation is out of your control. With a HSV node you could also tweak contrast of this desaturated texture. The below example takes the previous one further and desaturates the rusty flecks tex. for use in bump or roughness parameter of glossy metal material. It also changes the contrast.
2.) c) A gamma node de-coupled from image texture node..
And a way to separately control gamma(s) of a multitude of textures, by a single input value (pin). A material macro can be arbitrary complex. A user can be presented with the option to input an image texture pattern (for a wood or textile, for example), that is used in multiple operations throughout the macro internals - the image is the same but the gamma of the image (possibly and usually) needs to be different for every operation.
The same goes for every texture parameter (scale, power, etc...) - see the
5.) Basic math nodes request in the first post.
Basically this falls in the problem of "
being able to keep constant the ratio between a multitude of same-category parameters inside the macro, based on just one user-inputed value from outside". Users will not like to work with separate scale or gamma parameters for every texture in the macro.
2.) d) Logical operators
This one is a little more advanced and just an idea, but bear with me
With material abstraction on a higher level (see the end of the post for explanation), there is the need for more control and different ways to interpret user data. You could offer even more flexibility with one material macro, if you could be able to exclude or include parts of the macro internal pipeline from the calculation, based on boolean user input (or any other input evaluation - float, int, arbitrary input pin set / not set by user, etc...).
Say you created a carpaint material, and want to allow the user to choose if the paint has specks or not. Or if a textile material has sheen (mix diffuse with glossy in the final result) or not (don't mix glossy in the final result). Or being able to choose between adding hammering effect to copper material or not... You would need an
if-then-else node to bypass or include certain calculations in the macro internals, based on boolean user input (a complicated way to say
checkbox 
). Logical operators could also work on numbers (check if a certain input value is in a range, less than, greater of -> steer the pipeline accordingly) or on presence of user inputs (a user didn't input a pattern image texture -> use a procedural default). A myriad of options...
With more powerful macros the LiveDB will be smaller (no need for billions of generic carpaint materials), easier to find way around, and more manageable (of course this comes at a price of macros that are more difficult to create and manage - but that's not a problem of artists).
***** Explanation for the necessity of all this stuff (or at least my interpretation): *****
Of course users who create (or buy) image textures and import them for all standard shader parameters (diffuse, spec, bump..), will hardly see the point in all this. But I'm mainly thinking about the LiveDB here. For the LiveDB to
not be just another grouping of pre-made image textures with a multitude of generic shaders, the creators of material macros (and texture / emission macros) will need all this tools to present users with a powerful and flexible
material abstraction.
For example; in other material repositories the user downloads a leather-like shader and tweaks it's shader level parameters (bumpiness, specularity...), but (I sincerely hope) LiveDB could be different - the user downloads a leather material and it's parameters are of a higher abstraction level; eg. the user inputs density of cracks of leather, directionality of cracks, how worn out the leather is (that's controllable not just by spec, but also roughness and bump), etc... Basically users will work with real-life material characteristics, not low-level shader parameters. Of course you can open a material macro and see what's inside, maybe tweak something, but you shouldn't need to. A properly constructed material macro will offer the user all (in a practical limit) tweak-able options of a real-world material. For this to happen, we need a lot of pixel-manipulating features and other components that will allow powerful manipulation of data inside a macro.
This may sound complicated to some of you, but in the end all this technical features will bring the most to those artists who don't like all this technical stuff - you'll be able to completely ignore them and work with materials on a higher abstraction level
This is just my "little" rant.
Feel free to add everything you would like to say (in regard of material pipeline) - we need to state our opinions and wishes to the devs now, while Octane is still beta.
Cheers!
