MySQLi-extension class (parameterized queries)

Ok, you've posted quite a lot of code, and I have a few issues with some of it, that haven't been addressed by the accepted answer.
As usual, I'll walk through your code, pointing out omissions, mistakes, things that could be improved... along the way.

class p_mysqli extends mysqli

Stop. Yes, I have some criticism concerning the very first statement already. First off, this is a bit of a hang-up of mine: Please, please stick to coding standards as much as you can.
A class starts with an UpperCase character. Non-static methods (like your QueryParam) start with a lower-case, and are camleCased. Read through the linked PSR files, and try to stick to the recommendations. PHP doesn't have an official standard yet, but the more the PHP-FIG standard is adopted and advocated, the more likely it'll become a standard.

The other issue I have with this class is that it extends a core class. I've given a lengthy review on this site of code that extended PDO. The bottom line is: Avoid extending a class that you don't own.

Onwards, inside your constructor, you have this:

@parent::__construct($host, $user, $pass, $db, $port, $socket);

2 things bug me here: If your constructor merely calls the parent constructor, why bother writing that constructor in the first place... Inheritance means that, if a method is not defined on the child, then the parent's method will be called instead. Creating a method that just forwards to the parent's method is adding noise, and overhead: each method call takes time and resources. Not that you'll notice it that much, but it's just so pointless.

The other thing that really gets my goat here, is the fact that you use the @ suppressor of death. Again, I've been quite vocal in my intense loathing of this operator before, here for example. An error/notice is trying to tell you something isn't quite right, don't ignore it: fix it.
What's worse: you seem to be trying to suppress any problems that might occur in the constructor of an object???? That is just all shades of wrong: if a class can't be instantiated, don't you agree that the user (the one attempting to create that instance) should be notified? If an exception is thrown in a constructor, that means something fundamentally bad has occurred, and you shouldn't even think about carrying on.

If you can't connect to the DB in a MySQL class, then that class, and all code that uses it, can't do its job. trying to suppress errors in that scenario is like a serial killer denying everything, whilst covered in blood, with a pile of bodies behind him, and him holding a sign saying "I did it, and I'm proud of it, too".

But I'm drifting off topic here, badly. Carrying on!
Basically, the whole class is, just like I said in the answer with the PDO class, quite pointless IMO. I do understand the need to clean up mysqli's messy API, but extending a messy API isn't the right way to do it. A far better approach would be to create a wrapper object, which can implement this version of your QueryParam method:

public function queryParam($query, array $params)
{//use assoc array!
    $queryTypes = array_values($params);
    $queryParams = array_keys($params);
    //if needs must, you can use variable variables:
    $$queryParam[0] = 123;//but avoid, at all cost, I'd just bind to:
    $params[$queryTypes[0]];
}

You can then call this method like so:

$instance->queryParam(
    'SELECT * FROM foo WHERE bar = ? AND zar = ? AND x = ?',
    array(
        213  => 'i',
        431  => 'i',
       'abc' => 's'
    )
);

Using the values as keys may seem a bit odd, and it is. It can also cause issues when two parameters have the same value. That's why I think it best to either make the $param array 2 dimensional, pass a third argument ($types), or simply use the types of the arguments as they are being passed:

$typeString = '';
foreach ($params as $value)
{
    switch (true)
    {
        case is_int($value):
            $typeString  .= 'i';
            break;
        case is_string($value):
            $typeString .= 's';
            break;
        default:
            throw new \InvalidArgumentException(
                gettype($value). ' is not a valid query-param type'
            );
    }
}

A shorter, but more dangerous approach would be:

foreach ($params as $p)
    $typeString .= substr(gettype($p),0,1);//gets first char of type-string

Or, the less optimal, but safer approach:

foreach ($params as $k => $v)
    $params[$k] = (string) $v;
//types are all strings, let MySQL cast to the right type
$typeString = str_repeat('s', count($params));

Some other bits and pieces:

Passing by reference is the default for objects, explicit passing by reference is actually deprecated. So this:

$stateRet = call_user_func_array(
    array(
        &$statement,//$statement is an object
        'bind_param'
    ),
    $query
);

works best if you write it like so:

$stateRet = call_user_func_array(
    array(
        $statement,
        'bind_param'
    ),
    $query
);

Get rid of that &.

Another oddity in your code is this:

$arguments = func_get_args();
array_shift($arguments);
foreach ($params as $param)
    $queryParams[] = &$arguments[$lp[0]];

Basically, you're assigning a reference to each and every one of the arguments you passed to the function (except the query string, of course).
What's the point, I wonder? $queryParams is, 99.99% of the time going to end up being exactly the same as $arguments, why not simply write:

$arguments = func_get_args();
$queryParams = array_slice($arguments, 1);

Unless your query "recycles" a particular value like so:

foo = {0:i} AND bar = {0:i}

Just using the $arguments array will work just fine. You also say you want your method to work like .NET's String.format. Well, the niggle I have with that is simply this: you're not working with .NET here. Different languages tend to require different approaches for similar problems: use the tools you have. Forcing a language to work like another language is like trying to use a plane as a boat: Yes, you can sort of make it work, but it's just over-complicating things, and you're almost certainly going to find out it doesn't work as well as it could have.

Update:
After seeing your example, here's how you could apply my suggestions, and still be able to do the same thing:

public function queryParam($query, array $params, array $types = null)
{//I've made $types optional to show 2 possible approaches
    if ($types === null)
    {
        $types = array();
        foreach ($params as $param)
            $types[] = substr(gettype($param)), 0, 1);//boolean -> b, integer -> i, string -> s
            //float or double both yield "double" type -> d, which is what you need
    }
    $typeString = implode('', $types);//make string
    //optional validation of typeString:
    if (preg_match('/[^bsdi]/', $typeString))
        throw new InvalidArgumentException('unknown data types used');
    //add to params:
    array_unshift($typeString, $params);
    $stmt = $this->mysqli->prepare($query);
    call_user_func_array(
        array($stmt, 'bind_param'),
        $param
    );
    //this call_user_func_array equates to:
    $stmt->bind_param($typeString, $param[0], $param[1], $param[2],...);
}
//usage
$indb->queryParam(
    "SELECT COUNT(*) counted_column_test
        FROM users
    WHERE userid != ?
      AND disabled = ?
      AND email = ?",
    array(1, "[email protected]", false)
);
//or
$indb->queryParam(
    "SELECT COUNT(*) counted_column_test
        FROM users
    WHERE userid != ?
      AND disabled = ?
      AND email = ?",
    array(1, "[email protected]", false),
    array('i', 's', 'b')//<--optional
);

Oh, and BTW: userid != ? works, but the <> operator is more common... Some would even use userid NOT IN (?) here. Just thought you might want to know